Okay, as mentioned, I took my time tonight to look why X is so much faster with the Yocto image compared to Debian, and I think I found the reason.
First, I changed the Debian installation to use the driver "omap" instead of fbdev and copied the configuration over from the Yocto rootfs.
That sped things up a bit and made xrandr usable, but it was still slower then on Yocto.
With xrandr I could switch the resolution to 1280x720 and even 640x480, but it didn't increase the speed. Moving windows around was still stuttery, so it doesn't seem like a memory / bandwidth issue.
Checking /var/log/Xorg.0.log revealed what the real issue is:
On Debian, there is only the basic omap driver installed. It lacks DRI, DRI2 and PVR2D / XV drivers from TI. It clearly says it in the logfile ("XV not initialized" "Couldn't load submodule omap_pvr", etc.)
On the Yocto, it successfully initializes XV, DRI2, etc.
Unfortunately, Yocto uses X 1.11 and Debian 1.15, so I couldn't copy over the modules for testing.
It means however, that the slowness comes from missing OMAP driver modules, so we'd need to include them.
Seems like there's an Ubuntu Package: https://gitorious.org/ubuntu-omap/pvr-omap5/source/7b9f231fb44c03bc02f42b6bb...
There's also a prebuilt-OMAP5-Debian-Image available: http://elinux.org/BeagleBoardDebian#OMAP5432_uEVM
Haven't checked whether they have the drivers included or not though.
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
It means however, that the slowness comes from missing OMAP driver modules, so we'd need to include them.
Seems like there's an Ubuntu Package: https://gitorious.org/ubuntu-omap/pvr-omap5/source/7b9f231fb44c03bc02f42b6bb...
There's also a prebuilt-OMAP5-Debian-Image available: http://elinux.org/BeagleBoardDebian#OMAP5432_uEVM
Haven't checked whether they have the drivers included or not though.
I ran the pvr-omap5 stuff through my build setup, to compile debian testing versions of the packages, and to see if it would actually compile at all :)
it all seems to compile, although with a few annoying dependencies (like the ti-omap5 kernel), and the pvr-omap5-dkms package fails on the patching stage if you try to build from the git head directly. Building an older tagged version does work, but that is of course too old for the pvr-omap5 package itself.
I've dumped the results in here
http://next.openpandora.org/debian/testing/
which could theoretically be used by adding
deb [arch=armhf] http://next.openpandora.org/debian testing/ deb-src http://next.openpandora.org/debian testing/
to the apt sources.
It can't be used directly at this stage thanks to the version problems, but you could poke around in the files to see if there's anything useful in there.
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
On 07/10/2014 06:10 AM, aTc wrote:
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
I've fixed the package, doing an "apt-get install pvr-omap5" should pull in everything now. I did have to remove the dependency on linux-headers-ti-omap5 and linux-headers-omap5, so you have to make sure the pyra versions of those are in place. pvr-omap5-dkms should start building modules for the current kernel when it's beeing installed.
Am Thu, 10 Jul 2014 11:34:16 +0200 hat aTc atc@k-n-p.org geschrieben:
Thanks, that's great :) I'll try that tonight :)
On 07/10/2014 06:10 AM, aTc wrote:
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
I've fixed the package, doing an "apt-get install pvr-omap5" should pull in everything now. I did have to remove the dependency on linux-headers-ti-omap5 and linux-headers-omap5, so you have to make sure the pyra versions of those are in place. pvr-omap5-dkms should start building modules for the current kernel when it's beeing installed. _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
Am Thu, 10 Jul 2014 11:38:03 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Just a quick note: Didn't find the time to do last night, but will hopefully find time during the weekend.
Am Thu, 10 Jul 2014 11:34:16 +0200 hat aTc atc@k-n-p.org geschrieben:
Thanks, that's great :) I'll try that tonight :)
On 07/10/2014 06:10 AM, aTc wrote:
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
I've fixed the package, doing an "apt-get install pvr-omap5" should pull in everything now. I did have to remove the dependency on linux-headers-ti-omap5 and linux-headers-omap5, so you have to make sure the pyra versions of those are in place. pvr-omap5-dkms should start building modules for the current kernel when it's beeing installed. _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
Am Fri, 11 Jul 2014 16:15:28 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
okay, tried to install the package and so far it worked - but as Nikolaus kernel' doesn't have a linux-headers package, I can't run dkms :)
Nikolaus, would it be possible that you create proper kernel packages incl. header an image of your kernel setup?
Am Thu, 10 Jul 2014 11:38:03 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Just a quick note: Didn't find the time to do last night, but will hopefully find time during the weekend.
Am Thu, 10 Jul 2014 11:34:16 +0200 hat aTc atc@k-n-p.org geschrieben:
Thanks, that's great :) I'll try that tonight :)
On 07/10/2014 06:10 AM, aTc wrote:
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
I've fixed the package, doing an "apt-get install pvr-omap5" should pull in everything now. I did have to remove the dependency on linux-headers-ti-omap5 and linux-headers-omap5, so you have to make sure the pyra versions of those are in place. pvr-omap5-dkms should start building modules for the current kernel when it's beeing installed. _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
On 07/14/2014 02:16 AM, Michael Mrozek wrote:
Am Fri, 11 Jul 2014 16:15:28 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
okay, tried to install the package and so far it worked - but as Nikolaus kernel' doesn't have a linux-headers package, I can't run dkms :)
Nikolaus, would it be possible that you create proper kernel packages incl. header an image of your kernel setup?
I'd build it for you, but I don't know which kernel you're running on that board.
Am 14.07.2014 um 02:16 schrieb Michael Mrozek:
Am Fri, 11 Jul 2014 16:15:28 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
okay, tried to install the package and so far it worked - but as Nikolaus kernel' doesn't have a linux-headers package, I can't run dkms :)
Nikolaus, would it be possible that you create proper kernel packages incl. header an image of your kernel setup?
Yes. I just need to expand my build scripts a little to pack the headers.
And since I start over today with getting the LCD panels to work, I will run it several times a day anyways...
BR, Nikolaus
Am Thu, 10 Jul 2014 11:38:03 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Just a quick note: Didn't find the time to do last night, but will hopefully find time during the weekend.
Am Thu, 10 Jul 2014 11:34:16 +0200 hat aTc atc@k-n-p.org geschrieben:
Thanks, that's great :) I'll try that tonight :)
On 07/10/2014 06:10 AM, aTc wrote:
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
I've fixed the package, doing an "apt-get install pvr-omap5" should pull in everything now. I did have to remove the dependency on linux-headers-ti-omap5 and linux-headers-omap5, so you have to make sure the pyra versions of those are in place. pvr-omap5-dkms should start building modules for the current kernel when it's beeing installed. _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
Am 14.07.2014 um 02:16 schrieb Michael Mrozek:
Am Fri, 11 Jul 2014 16:15:28 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
okay, tried to install the package and so far it worked - but as Nikolaus kernel' doesn't have a linux-headers package, I can't run dkms :)
Nikolaus, would it be possible that you create proper kernel packages
a general alternative would be to unpack the full kernel.tbz sources:
http://download.goldelico.com/DragonFly/unstable/src/
incl. header an image of your kernel setup?
Ok, here is a first experiment to pack just the headers:
http://download.goldelico.com/DragonFly/unstable/
Please let me know if it works. I don't know what dkms really expects to be available and have tried to provide roughly the same files as this package:
https://packages.debian.org/wheezy/armhf/linux-headers-3.2.0-4-common/fileli...
And I looked what apt-get install dkms would try to install as dependencies:
linux-headers-3.2.0-4-common linux-headers-3.2.0-4-vexpress linux-headers-vexpress linux-image-3.2.0-4-vexpress linux-kbuild-3.2
This doesn't look sane for our OMAP5432EVM
BR, Nikolaus
Am Thu, 10 Jul 2014 11:38:03 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Just a quick note: Didn't find the time to do last night, but will hopefully find time during the weekend.
Am Thu, 10 Jul 2014 11:34:16 +0200 hat aTc atc@k-n-p.org geschrieben:
Thanks, that's great :) I'll try that tonight :)
On 07/10/2014 06:10 AM, aTc wrote:
On 07/10/2014 03:28 AM, Michael Mrozek wrote:
I could probably get it in a state where installable packages are created, but its far too late/early for that now :)
I've fixed the package, doing an "apt-get install pvr-omap5" should pull in everything now. I did have to remove the dependency on linux-headers-ti-omap5 and linux-headers-omap5, so you have to make sure the pyra versions of those are in place. pvr-omap5-dkms should start building modules for the current kernel when it's beeing installed. _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
On 07/14/2014 08:42 PM, Dr. H. Nikolaus Schaller wrote:
Am 14.07.2014 um 02:16 schrieb Michael Mrozek:
Am Fri, 11 Jul 2014 16:15:28 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
okay, tried to install the package and so far it worked - but as Nikolaus kernel' doesn't have a linux-headers package, I can't run dkms :)
Nikolaus, would it be possible that you create proper kernel packages
a general alternative would be to unpack the full kernel.tbz sources:
http://download.goldelico.com/DragonFly/unstable/src/
incl. header an image of your kernel setup?
Ok, here is a first experiment to pack just the headers:
http://download.goldelico.com/DragonFly/unstable/
Please let me know if it works. I don't know what dkms really expects to be available and have tried to provide roughly the same files as this package:
https://packages.debian.org/wheezy/armhf/linux-headers-3.2.0-4-common/fileli...
And I looked what apt-get install dkms would try to install as dependencies:
linux-headers-3.2.0-4-common linux-headers-3.2.0-4-vexpress linux-headers-vexpress linux-image-3.2.0-4-vexpress linux-kbuild-3.2
This doesn't look sane for our OMAP5432EVM
Even with the kernel headers its a bit of a fight to get it to compile (haven't even managed it so far, and i don't want to waste too much time on it), It's probably easier to integrate that module with the rest of the kernel, having to use dkms isn't something you really want anyway.
The package itself came from https://gitorious.org/ubuntu-omap/pvr-omap5-dkms
Hi,
On 07/10/2014 04:28 AM, Michael Mrozek wrote:
Okay, as mentioned, I took my time tonight to look why X is so much faster with the Yocto image compared to Debian, and I think I found the reason.
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
ED, is that the issue you want to fix?
I'm quite sure it's all because of limited memory bandwidth. Then why does Yocto + TI drivers work better, you may ask? That's because it's "cheating" and using basically what we call frameskip in emulators, i.e. simply not sending some frames to screen. I'll admit I'm making an assumption here, but there is simply no way it could pull that off otherwise, SGX can't do magic and move the memory 10x faster than ARM out of the sudden.
It's possible to do the same cheating thing in software, and a driver called fbturbo ( https://github.com/ssvb/xf86-video-fbturbo ) can do just that. Get http://notaz.gp2x.de/tmp/fbturbo_drv.so and copy to /usr/lib/xorg/modules/drivers/ then in xorg.conf set: Driver "fbturbo" Option "ForceBackingStore" "true" then restart X and test. It shouldn't be hard to make Debian package out of fbturbo, the deps are sane.
I think fbturbo is the driver we should ultimately use on Pyra and not the SGX blobs with all their mess. This will give better stability (misbehaving SGX driver won't bring the system down) and allow open source purists to use Pyra in default setup we support. fbturbo currently lacks video overlay support (only supports it on allwinner SoCs) and could make use of Vivante 2D accelerator that's sitting in OMAP5. I plan to work on that, I just don't know when. Won't be too easy but should be doable.
Grazvydas
Am Tue, 15 Jul 2014 03:08:56 +0300 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Hi,
On 07/10/2014 04:28 AM, Michael Mrozek wrote:
Okay, as mentioned, I took my time tonight to look why X is so much faster with the Yocto image compared to Debian, and I think I found the reason,
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
ED, is that the issue you want to fix?
Yep, exactly. That makes the system feel slow and sluggish.
I'm quite sure it's all because of limited memory bandwidth. Then why does Yocto + TI drivers work better, you may ask? That's because it's "cheating" and using basically what we call frameskip in emulators, i.e. simply not sending some frames to screen. I'll admit I'm making an assumption here, but there is simply no way it could pull that off otherwise, SGX can't do magic and move the memory 10x faster than ARM out of the sudden.
Hm, but TI also made some presentations of the OMAP5, e.g. here: http://youtu.be/Z2nAqKfDmb0?t=4m24s
A HTML5 rendered caroussel with animated stuff. Pretty impressive. Is that because it uses OpenGLES for rendering background instead of X?
It's possible to do the same cheating thing in software, and a driver called fbturbo ( https://github.com/ssvb/xf86-video-fbturbo ) can do just that.
I just tried it - and yes, it certainly improved things a lot. It can't do magic (Wesnoth in FullHD is still stuttering), but windows move a lot more fluid. Could need some tweaks though, as it sometimes needs 1 - 2 seconds before the window actually moves - and then it's fluid.
I think fbturbo is the driver we should ultimately use on Pyra and not the SGX blobs with all their mess. This will give better stability (misbehaving SGX driver won't bring the system down) and allow open source purists to use Pyra in default setup we support. fbturbo currently lacks video overlay support (only supports it on allwinner SoCs) and could make use of Vivante 2D accelerator that's sitting in OMAP5. I plan to work on that, I just don't know when. Won't be too easy but should be doable.
Well, we could grab some other things from the OMAP driver as well. e.g., OMAP supports xrandr, which is neat, as you can change the resolution to 1280x720 for HDMI out (which increases the rendering speed).
Best is probably a mixture of all of that.
Hi, here my 2ct of experiences for this issue.
Am 15.07.2014 um 02:08 schrieb Grazvydas Ignotas:
Hi,
On 07/10/2014 04:28 AM, Michael Mrozek wrote:
Okay, as mentioned, I took my time tonight to look why X is so much faster with the Yocto image compared to Debian, and I think I found the reason.
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
This looks like an X-event/GUI-library issue to me. Maybe the client code tries to redraw for each event even if the window is just moved around (which can be done bit blitting in the x server).
Ah, yes. This is very likely. If you move a window - and have the wrong settings for backing store, this creates redraw events for each rectangle that becomes unobscured by moving the window away. This redraw event is sent to the client which must render the portion of the screen again.
If there is backing store enabled, the portion becoming unobscured can be redrawn from some buffer within the X server.
ED, is that the issue you want to fix?
I'm quite sure it's all because of limited memory bandwidth. Then why does Yocto + TI drivers work better, you may ask? That's because it's "cheating" and using basically what we call frameskip in emulators, i.e. simply not sending some frames to screen. I'll admit I'm making an assumption here, but there is simply no way it could pull that off otherwise, SGX can't do magic and move the memory 10x faster than ARM out of the sudden.
I have doubts about your theory of limited memory bandwidth.
On the GTA04 (or OpenPandora) we have 640x480 pixels which is just 1/7 of Full-HD. So the OMAP5 should not have to do more than 7 times as much work and bandwidth demand as the OMAP3.
On a memory system with at least 4 times the bandwidth.
So it should be barely noticeable.
Rather if you see a window lagging several seconds behind mouse movements it should give a noticeable effect (e.g. 3/7 seconds) on the OpenPandora as well.
But I have never seen such effects on the GTA04 (unless induced by badly programmed X clients). Even Replicant (Android) is running smoothly without any acceleration.
What could be is that the fbdev driver has some bug that is throttling it down heavily (e.g. waiting for a vsync for each block moved on the screen). But I don't know well enough how fbdev works.
It's possible to do the same cheating thing in software, and a driver called fbturbo ( https://github.com/ssvb/xf86-video-fbturbo ) can do just that. Get http://notaz.gp2x.de/tmp/fbturbo_drv.so and copy to /usr/lib/xorg/modules/drivers/ then in xorg.conf set: Driver "fbturbo" Option "ForceBackingStore" "true" then restart X and test. It shouldn't be hard to make Debian package out of fbturbo, the deps are sane.
I think fbturbo is the driver we should ultimately use on Pyra and not the SGX blobs with all their mess. This will give better stability (misbehaving SGX driver won't bring the system down) and allow open source purists to use Pyra in default setup we support. fbturbo currently lacks video overlay support (only supports it on allwinner SoCs) and could make use of Vivante 2D accelerator that's sitting in OMAP5. I plan to work on that, I just don't know when. Won't be too easy but should be doable.
BR, Nikolaus
Am 15.07.2014 um 08:10 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Hi, here my 2ct of experiences for this issue.
Am 15.07.2014 um 02:08 schrieb Grazvydas Ignotas:
Hi,
On 07/10/2014 04:28 AM, Michael Mrozek wrote:
Okay, as mentioned, I took my time tonight to look why X is so much faster with the Yocto image compared to Debian, and I think I found the reason.
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
This looks like an X-event/GUI-library issue to me. Maybe the client code tries to redraw for each event even if the window is just moved around (which can be done bit blitting in the x server).
Ah, yes. This is very likely. If you move a window - and have the wrong settings for backing store, this creates redraw events for each rectangle that becomes unobscured by moving the window away. This redraw event is sent to the client which must render the portion of the screen again.
If there is backing store enabled, the portion becoming unobscured can be redrawn from some buffer within the X server.
ED, is that the issue you want to fix?
I'm quite sure it's all because of limited memory bandwidth. Then why does Yocto + TI drivers work better, you may ask? That's because it's "cheating" and using basically what we call frameskip in emulators, i.e. simply not sending some frames to screen. I'll admit I'm making an assumption here, but there is simply no way it could pull that off otherwise, SGX can't do magic and move the memory 10x faster than ARM out of the sudden.
I have doubts about your theory of limited memory bandwidth.
On the GTA04 (or OpenPandora) we have 640x480 pixels which is just 1/7 of Full-HD. So the OMAP5 should not have to do more than 7 times as much work and bandwidth demand as the OMAP3.
On a memory system with at least 4 times the bandwidth.
So it should be barely noticeable.
Rather if you see a window lagging several seconds behind mouse movements it should give a noticeable effect (e.g. 3/7 seconds) on the OpenPandora as well.
But I have never seen such effects on the GTA04 (unless induced by badly programmed X clients). Even Replicant (Android) is running smoothly without any acceleration.
What could be is that the fbdev driver has some bug that is throttling it down heavily (e.g. waiting for a vsync for each block moved on the screen). But I don't know well enough how fbdev works.
Just another idea: do we have to assign more RAM to the graphics system?
It's possible to do the same cheating thing in software, and a driver called fbturbo ( https://github.com/ssvb/xf86-video-fbturbo ) can do just that. Get http://notaz.gp2x.de/tmp/fbturbo_drv.so and copy to /usr/lib/xorg/modules/drivers/ then in xorg.conf set: Driver "fbturbo" Option "ForceBackingStore" "true" then restart X and test. It shouldn't be hard to make Debian package out of fbturbo, the deps are sane.
I think fbturbo is the driver we should ultimately use on Pyra and not the SGX blobs with all their mess. This will give better stability (misbehaving SGX driver won't bring the system down) and allow open source purists to use Pyra in default setup we support. fbturbo currently lacks video overlay support (only supports it on allwinner SoCs) and could make use of Vivante 2D accelerator that's sitting in OMAP5. I plan to work on that, I just don't know when. Won't be too easy but should be doable.
BR, Nikolaus
Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
Am Tue, 15 Jul 2014 08:10:37 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
just tried a few more things with that turbo driver.
Moving windows is a lot faster (after the initial hang), as mentioned. Battle for Wesnoth is still really slow, which was to be expected, as it's updating the fullscreen, the trick the turbo used wouldn't have helped here.
I switched Wesnoth to window mode. If the Window is roughly 1024x768 in size, Wesnoth is smooth and blazing fast. The bigger it is, the more stuttery it gets, so it's certainly something that has to to with refreshing the screen.
I'm not sure how smart X works. For example, if you move the map in Wesnoth, does it redraw the full screen as every pixel changes, or is it smart enough to figure out that the content has just moved a bit and moves it instead of redrawing it completely? (That's how video compression works)
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
This looks like an X-event/GUI-library issue to me. Maybe the client code tries to redraw for each event even if the window is just moved around (which can be done bit blitting in the x server). Ah, yes. This is very likely. If you move a window - and have the wrong settings for backing store, this creates redraw events for each rectangle that becomes unobscured by moving the window away. This redraw event is sent to the client which must render the portion of the screen again.
Is that a setting you can apply somewhere? I didn't find anything like that in X' configuration options. Or is that something that needs to be fixed in the driver?
If there is backing store enabled, the portion becoming unobscured can be redrawn from some buffer within the X server.
Okay, so I guess that's basically what I mentioned above with Wesnoth as well? If the screen portion moves, no need to redraw it but simply move it?
I have doubts about your theory of limited memory bandwidth. On the GTA04 (or OpenPandora) we have 640x480 pixels which is just 1/7 of Full-HD. So the OMAP5 should not have to do more than 7 times as much work and bandwidth demand as the OMAP3.
Are you using 32bpp or 16bpp? The Pyra is currently using 32bpp, which increases the bandwidth a lot as well (though the question is whether we even need 32bpp)
Am 15.07.2014 um 12:49 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Tue, 15 Jul 2014 08:10:37 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
just tried a few more things with that turbo driver.
Moving windows is a lot faster (after the initial hang), as mentioned. Battle for Wesnoth is still really slow, which was to be expected, as it's updating the fullscreen, the trick the turbo used wouldn't have helped here.
I switched Wesnoth to window mode. If the Window is roughly 1024x768 in size, Wesnoth is smooth and blazing fast. The bigger it is, the more stuttery it gets, so it's certainly something that has to to with refreshing the screen.
I'm not sure how smart X works. For example, if you move the map in Wesnoth, does it redraw the full screen as every pixel changes, or is it smart enough to figure out that the content has just moved a bit and moves it instead of redrawing it completely? (That's how video compression works)
I think in X it depends on what the client application instructs the X-Server to do. There are move-commands and it is possible to redraw a bitmap at a different location.
I've tried the fbdev driver again and it acted pretty much as I expected. Small windows moved fast on top of black background, but created "trails" if moved on top of other windows (say if you have Iceweasel with a rendered web page at the background). Large windows (like the same Iceweasel) lag behind, i.e. the move animation may still show several seconds after you stopped moving your mouse.
This looks like an X-event/GUI-library issue to me. Maybe the client code tries to redraw for each event even if the window is just moved around (which can be done bit blitting in the x server). Ah, yes. This is very likely. If you move a window - and have the wrong settings for backing store, this creates redraw events for each rectangle that becomes unobscured by moving the window away. This redraw event is sent to the client which must render the portion of the screen again.
Is that a setting you can apply somewhere? I didn't find anything like that in X' configuration options. Or is that something that needs to be fixed in the driver?
IMHO this is chosen by the GUI toolkit. Or maybe a X server command line option?
Graphics Memory size was on the bootargs of the BeagleBoard but I don’t know if it still exists on the OMAP5 kernel.
If there is backing store enabled, the portion becoming unobscured can be redrawn from some buffer within the X server.
Okay, so I guess that's basically what I mentioned above with Wesnoth as well? If the screen portion moves, no need to redraw it but simply move it?
I have doubts about your theory of limited memory bandwidth. On the GTA04 (or OpenPandora) we have 640x480 pixels which is just 1/7 of Full-HD. So the OMAP5 should not have to do more than 7 times as much work and bandwidth demand as the OMAP3.
Are you using 32bpp or 16bpp? The Pyra is currently using 32bpp, which increases the bandwidth a lot as well (though the question is whether we even need 32bpp)
Hm. I don’t know for sure. Most likeley it is 24bpp (since we have a 24bit WVGA panel on the Letux 7004).
32bpp is not really needed but should IMHO even be faster since it does has a direct memory-word <-> pixel mapping. 24bpp might need to read two memory words (32 bits each) to get a pixel.
Okay, here are some quick tests with gtkperf.
First, the short hang when moving windows only happens when using KDE. KDE also has a slower performance with gtkperf (about 2 seconds). With LXDE and XFCE4, using the turbofb driver is awesome - feels as fast as my normal desktop PC - and that's with FULLHD 32bpp!
Was to be expected, I guess ;)
OMAP driver (well, without the SGX stuff) is about half speed of fbturbo. And fbdev was even slower than the OMAP driver (didn't run a test with that though).
BTW: When I set the framebuffer to 16bit (fbset -depth 16), X has garbled graphics, so I couldn't compare 16bit vs 32bit.
Here are the gtkperf results:
fbturbo:
GtkPerf 0.40 - Starting testing: Mon Jul 21 23:09:54 2014
GtkEntry - time: 0.14 GtkComboBox - time: 2.61 GtkComboBoxEntry - time: 2.10 GtkSpinButton - time: 0.23 GtkProgressBar - time: 0.13 GtkToggleButton - time: 0.15 GtkCheckButton - time: 0.08 GtkRadioButton - time: 0.13 GtkTextView - Add text - time: 0.48 GtkTextView - Scroll - time: 0.18 GtkDrawingArea - Lines - time: 1.19 GtkDrawingArea - Circles - time: 2.38 GtkDrawingArea - Text - time: 0.49 GtkDrawingArea - Pixbufs - time: 0.08 --- Total time: 10.40
OMAP: GtkPerf 0.40 - Starting testing: Mon Jul 21 23:13:17 2014
GtkEntry - time: 0.17 GtkComboBox - time: 1.96 GtkComboBoxEntry - time: 1.37 GtkSpinButton - time: 0.12 GtkProgressBar - time: 0.17 GtkToggleButton - time: 0.15 GtkCheckButton - time: 0.18 GtkRadioButton - time: 0.23 GtkTextView - Add text - time: 1.78 GtkTextView - Scroll - time: 1.23 GtkDrawingArea - Lines - time: 3.82 GtkDrawingArea - Circles - time: 4.55 GtkDrawingArea - Text - time: 4.64 GtkDrawingArea - Pixbufs - time: 1.05 --- Total time: 21.44