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

[Stephan Kanthak]

Hi Prabindh,

I think my last posting wasn't that precise.

The TI package clearly lacks VSYNC support for OMAP4. None of the SDK demos runs at a constant frame rate (some at 150+ fps), none of them uses a blocking vsync ioc

Stephan


On 20.11.2012, at 13:30, "Sundareson, Prabindh" <prabu at ti.com> wrote:

> 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.
> 
> 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 1:32 PM
> To: interest at qt-project.org
> Subject: Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
> 
> 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
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest