[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
prabu at ti.com
Tue Nov 20 13:30:51 CET 2012
Good to know that the flip mode solved the issue. You might want to update to a later kernel revision and check. Vsync handling is more complex than it appears, over fb drivers.
From: interest-bounces+prabu=ti.com at qt-project.org [mailto:interest-bounces+prabu=ti.com at qt-project.org] On Behalf Of Stephan Kanthak
Sent: Tuesday, November 20, 2012 1:32 PM
To: interest at qt-project.org
Subject: Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
couldn't wait, so I already tried yesterday, but then went to bed :-).
It worked immediately! I added an ioctl(fbdev, WAITFORSYNC) to
after that all animations were butter smooth immediately. I also noticed
that there was constant tearing somewhere close to the top of the
display. After adding ioctl(fbdev, WAITFORSYNC) to PVRShell.cpp I had
the same tearing already on all SGX demos and already noticed that I was
still using the LINUXFB driver that doesn't use the flip chain.
So, everything is perfectly smooth now, except maybe when I enable FSAA
in complex scenes, but most likely the SGX core bows quickly then :-).
The only remaining question is, why does the egl driver not wait for
vsync? I think that's what also the PVR demos assume. Some of them run
at high frame rates, but should instead never exceed the displays
refresh rate. Or is there a known bug for OMAP4 with the driver release
I use? I've found a post on some Google group from January this year:
where someone notices exactly the same with that driver release
(Pandaboard, FBDEV => no vsync on eglSwapBuffers). According to that
thread, the Linaro/Ubuntu driver seems to use it, but only under certain
Although I know now how to "hack" it, any idea?
I also feel like this thread should move now to either some TI-SXG- or
-dev mailing list, or is it fine to finish the discussion here?
On 11/20/2012 03:21 AM, Sundareson, Prabindh wrote:
> Did you try flipwsegl, as specified in below link ? From your last log, you were using linuxfbwsegl.
> - Moving to flip will reduce the framerate
> - If you still see tearing with flip, ensure you really have 3 flipbuffers allocated, and the fb driver really waits for vsync. There were issues with older versions of fb that did not properly support waiting for vsync, atleast on OMAP3.
> -----Original Message-----
> From: interest-bounces+prabu=ti.com at qt-project.org [mailto:interest-bounces+prabu=ti.com at qt-project.org] On Behalf Of Stephan Kanthak
> Sent: Tuesday, November 20, 2012 6:40 AM
> To: Donald Carr
> Cc: interest at qt-project.org
> Subject: Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
> Hi Donald,
> On 11/19/2012 10:54 PM, Donald Carr wrote:
>> On top of all of this, I saw weird partial updates on all the OMAP SGX
>> based devices I tested against Qt 5. I have a beagle board video
>> uploaded which shows the screen broken up into 4 discrete quadrants
>> which are alternately updated.
> I did make good progress this evening :-). The TI demos do all tear. I
> now traced it down to no vsync at all! My assumption was that these
> demos do instead use vsync, but in fact they don't. Only
> OGLES2ChameleonMan did not seem to tear, but I think only by chance, as
> the frame rate it uses to predict animation was almost exactly matching
> 3 times the frame update frequency.
> I actually tried a couple of things, but finally explicitly waiting for
> VSYNC within the OMAP display subsystem (DSS) does perfectly vsync all
> demos (an now I've proof for the Kindle Fire's 50Hz panel, too :-) )!
> I'll try to test that on qt5/eglfs tomorrow. Unfortunately, in the
> 2.6.35 kernel that I'm using OMAP DSS does not yet handle the generic
> FBIO_WAITFORVSYNC, but instead uses own ioctls. I've seen that more
> recent omap kernels also catch FBIO_WAITFORVSYNC. I'm not sure wether
> other framebuffer drivers handle this in the same way.
Interest mailing list
Interest at qt-project.org
More information about the Interest