Yes, screen response time matters in what the unit is -capable- of producing. I'm pretty sure the screen -can- do it, it is a very nice screen.Yep. Of course size/speed matters and also the screen response time. If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).
Careful about those manufacturer-provided response times, though, they do not apply to generic color switches. The most dominant value advertised for PC monitors is the gray-to-gray response time - simply because it commonly is the lowest, and that motivates a lot of manufacturers to cheat by optimizing their low-cost screens only for that value. I do not expect this to be an issue on embedded screens for mobile devices, but you should still always handle them with a grain of salt, especially if you want to compare them to calculated absolute limits. The worst-case scenario will always take a lot longer than the advertised gray-to-gray response time.If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).
That's the theory. However, the black-to-white metric provides a kind of worst-case value whereas the gray-to-gray value might provide something more similar to the average usage, but it is also much more akin to meddling.The grey-to-grey time was meant to be an improvement on the old black-to-white measurement
...if there was a standardized measurement method to actually generate the metrics, black-to-white response times are not just a worst-case value but also part of an ISO standard. Gray-to-gray on the other hand is pretty much a bullshit PR value.Thankfully publishing grey-to-grey metrics largely stopped those kind of shenanigans for a good few years now.
That wikipedia page doesn't say a word about screen size.Actually, screen size makes a big difference in where the threshold for animation occurs.
From the page: https://en.wikipedia.org/wiki/Frame_rate
You can just use ctrl +/- to resize the 12fps gif.
Sized down to about 2" it barely meets the threshold of animation, but your mind perceives it as animated.
Sized up to about 5" it appears quite choppy.
Sized up to 12" it's 'unwatchable'.
Games that will appear choppy as hell at 20fps on a 21" screen will be quite playable at 20fps on a 5" screen.
I would argue, then, that processing cycles being used to generate frame rates on a mobile device that are higher than 'needed' (admittedly variable on many factors) aren't doing any 'good' and are doing basic 'harm' to the experience by wasting battery power by turning it into heat without enhancing the user experience.
Where that threshold is will be variable on the user and the application/game being used. If we were to be able to put in a user configurable 'restriction' at the .dbp layer (so that it is application dependent), that would allow the device user to be able to adjust up/down how much CPU gets allocated to the application - which translates into a choice between battery life or frame rate - and would let the user choose where that balance best suits them.
That is the idea. I don't know if it is possible to implement. But, as is, 'greedy apps' will draw every scrap of CPU they can, regardless of whether doing so actually improves the perceived user experience.
the point was to save battery and heat build up. just running another process wont achieve anything.
CPS3 already run pretty well on Pandora, can't tell if it was solid 60fps, but it felt prefectly smooth on a Ghz edition. I'm absolutely sure that Pyra can do perfect CPS3 emulation.Hope everyone had a good Christmas and New year.
Really excited to see the Pyra ever closer to mass production. Can't wait to get one. I follow retro gaming on many other devices as well as Pyra and there is one particular retro handheld device available called the GKD350h which uses a custom made Ingenic X1830 running at 1.5ghz. It lacks a GPU but is a 2d powerhouse has been tested running CPS3 arcade games at 60 fps fullspeed using the Fba emulator which is amazing!
The Pyra obviously uses a different CPU but since it also runs at 1.5ghz, I really hope that it will also be capable of emulating the CPS3 arcade games at 60fps. Could this be tested at some point later on the dev or prototype units?
It took me a bit to work through and combine what aTc said above with how I know that the process works from having done it a few times. I thought it might help the other Pyra prototype owners if I made a stepwise instructions set for installing the OS fresh to the eMMC card. If it doesn't, then the only time I wasted was my own.I've created some new os images.
the img.zip need to be unpacked, then written to an sd card.
If you've previously made an installer sd card, you can remove the rootfs.tgz from that, copy pyra-debian-buster-mate-rootfs.tgz to the card, and rename it to rootfs.tgz , it can then be used to flash the new image.
These include bluetooth and modemmanager, and uses the uboot version that doesn't remove the emmc when the shoulderbutton is pressed.
To update without reflashing the entire emmc/sd card, you can just do an "apt update; apt upgrade"
Because i forgot to add some packages, you also need to do a "apt install pyra-meta-extra" to get the bt/etc stuff.
Updating uboot also needs to be done manually, which can be done with "sudo /usr/share/pyra/scripts/pyra-install-uboot.sh /usr/share/pyra/u-boot/pyra-u-boot-4g/ /dev/mmcblk0"
Replace /dev/mmcblk0 with /dev/mmcblk3 if you're running from sd, (or just look at the output of lsblk, and use the device that has the /boot partition on it (without any p1 added to the end))
the -nobat image is still the old one, so don't use that.
To set up a mobile broadband connection, open the mate menu and go to System Tools->Modem Manager GUI ( wait for the modem to appear, it takes about 256 seconds after booting)
On the Connection bar, click "Edit" , "Add connection" and make sure all values are right. "Ok" , then click "Activate" and it should all work.
OK.There are several mechanisms, of different utility and complexity. nice, cpulimit and cgroups. cgroups is a general resource controller which is complicated to set up, but has most flexibility.
The Linux kernel is an incredible circus performer, carefully juggling many processes and their resource needs to keep your server humming ascoutapm.com
I recommend reading up on cgroups, because as well as enforcing relative cpu usage restrictions (e.g. one process gets twice as much as another if they are competing for the same thing), you can also set cpu usage ceilings with the cpu.cfs_period_us and cpu.cfs_quota_us ( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/sec-cpu#sect-cfs ).
I don't know if the letux kernel offers the cgroups capability, and if so, whether it is V1 or V2.
# mount | grep cgroup tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
# cd /sys/fs/cgroup/cpu # ls -1 cgroup.clone_children cgroup.procs cgroup.sane_behavior cpuacct.stat cpuacct.usage cpuacct.usage_all cpuacct.usage_percpu cpuacct.usage_percpu_sys cpuacct.usage_percpu_user cpuacct.usage_sys cpuacct.usage_user cpu.cfs_period_us cpu.cfs_quota_us cpu.shares cpu.stat notify_on_release release_agent tasks # cat /sys/fs/cgroup/cpu/cpu.cfs_period_us 100000
#cgcreate -g cpu:/fixedlimit
# ls -1 /sys/fs/cgroup/cpu cgroup.clone_children cgroup.procs cgroup.sane_behavior cpuacct.stat cpuacct.usage cpuacct.usage_all cpuacct.usage_percpu cpuacct.usage_percpu_sys cpuacct.usage_percpu_user cpuacct.usage_sys cpuacct.usage_user cpu.cfs_period_us cpu.cfs_quota_us cpu.shares cpu.stat fixedlimit notify_on_release release_agent tasks
# ls -1 /sys/fs/cgroup/cpu/fixedlimit cgroup.clone_children cgroup.procs cpuacct.stat cpuacct.usage cpuacct.usage_all cpuacct.usage_percpu cpuacct.usage_percpu_sys cpuacct.usage_percpu_user cpuacct.usage_sys cpuacct.usage_user cpu.cfs_period_us cpu.cfs_quota_us cpu.shares cpu.stat notify_on_release tasks
# cgset -r cpu.cfs_period_us=100000 fixedlimit # cgset -r cpu.cfs_quota_us=25000 fixedlimit
# cat /sys/fs/cgroup/cpu/fixedlimit/cpu.cfs_period_us 100000 # cat /sys/fs/cgroup/cpu/fixedlimit/cpu.cfs_quota_us 25000
# cgexec -g cpu:fixedlimit /my/hungry/program
There are control groups capabilities that can restrict/bind the process to a single cpu, and if the game operates by forking of a set of sub-processes, it is possible to ensure that they are captured in the same overall cpu use restrictions.Ceiling Enforcement Tunable Parameters
specifies a period of time in microseconds (µs, represented here as "us") for how regularly a cgroup's access to CPU resources should be reallocated. If tasks in a cgroup should be able to access a single CPU for 0.2 seconds out of every 1 second, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 1000000. The upper limit of the cpu.cfs_quota_us parameter is 1 second and the lower limit is 1000 microseconds.
specifies the total amount of time in microseconds (µs, represented here as "us") for which all tasks in a cgroup can run during one period (as defined by cpu.cfs_period_us). As soon as tasks in a cgroup use up all the time specified by the quota, they are throttled for the remainder of the time specified by the period and not allowed to run until the next period. If tasks in a cgroup should be able to access a single CPU for 0.2 seconds out of every 1 second, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 1000000. Note that the quota and period parameters operate on a CPU basis. To allow a process to fully utilize two CPUs, for example, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 100000.
Setting the value in cpu.cfs_quota_us to -1 indicates that the cgroup does not adhere to any CPU time restrictions. This is also the default value for every cgroup (except the root cgroup).
# apt list cgroup-tools
Listing... Done cgroup-tools/bionic,now 0.41-8ubuntu2 amd64
Listing... Done cgroup-tools/bionic,now 0.41-8ubuntu2 amd64 [installed]
# apt install cgroup-tools
It's far safer to just use a disk image writing tool instead of messing about with dd.It took me a bit to work through and combine what aTc said above with how I know that the process works from having done it a few times. I thought it might help the other Pyra prototype owners if I made a stepwise instructions set for installing the OS fresh to the eMMC card. If it doesn't, then the only time I wasted was my own.
4. Navigate to the folder where you have extracted the file pyra-install.img.
5. Insert an SD card in a reader into a USB drive on the workstation.
6. fdisk -l to list the disk devices on your Linux workstation. In my case the target SD card in a USB reader is /dev/sdj. MAKE SURE YOU GET THIS RIGHT! The next step could overwrite your main OS on the workstation if you get the wrong device!
7. dd if=./pyra-install.img of=/dev/sdj bs=1M; sync Wait for the sync to complete and return to the # prompt.
You can skip all that, the latest image already has that stuff included.Now to take care of getting the 'extras' and uboot set up right.
And isn't present in the debian repository, requiring side-loading an additional application binary and learning how to use it.It's far safer to just use a disk image writing tool instead of messing about with dd.
raspberrypi points you to https://www.balena.io/etcher/ for example, which has a nice gui where you can just select the .img.zip and an sd card and it'll write it. Also works on mac and windows.
You're right - I figured that out after I had already done it. A few extra unneeded steps in the above then if anyone decides to write it up again for a Wiki.You can skip all that, the latest image already has that stuff included.
That part is only needed if you have an old install and don't want to lose everything by doing a reinstall.