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....@qt-project.org
> [mailto:interest-bounces+prabu=ti....@qt-project.org] On Behalf Of Stephan
> Kanthak
> Sent: Tuesday, November 20, 2012 6:40 AM
> To: Donald Carr
> Cc: interest@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
