[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour

[Stephan Kanthak]

Hi Prabindh,

couldn't wait, so I already tried yesterday, but then went to bed :-).

It worked immediately! I added an ioctl(fbdev, WAITFORSYNC) to
qt/qtbase/src/platformsupport/eglconvenience/qeglplatformcontext.cpp and 
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:

     https://groups.google.com/forum/#!topic/pandaboard/Ig7VrOU_zW8

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 
circumstances.

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?

Best,
Stephan

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.
>
> http://processors.wiki.ti.com/index.php/SGXDbg#Vertical_Tearing
>
> Note:
>
> - 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.
>
> regards
> Prabindh
>
>
> -----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.
>
> Best,
> Stephan