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