[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
stylon at gmx.de
Tue Nov 20 13:59:51 CET 2012
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
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.
> -----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:
> 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