Stephan - Waiting for vsync in user mode is quite different from hooking onto the vsync from kernel (in omaplfb), and ltrace/strace would not show waiting in the kernel mode.
Since this is TI specific, and the Qt5 specific issue seems to be resolved, please send me a direct mail, if so required. 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 PM To: interest@qt-project.org Subject: Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour Hi Prabindh, that one went out too quickly... :-) I think my last posting wasn't that precise. The TI package I'm using 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 ioctl (simply ltrace/strace and you'll noice). On the other hand, the kernel 2.6.35 that I'm using does have working VSYNC and it would be as easy to fix as adding that ioctl to eglSwapBuffers(). That's basically what I've done to both PVRShell from the SDK and Qt5Beta1. Switching to the flip chain driver simply removed the single remaining tearing line, which certainly makes, because that's exactly what I assume would happen witha single buffer+ vsync. Taking into account the info from Samuel's post it's obvious that the TI driver is simply lacking VSYNC support for OMAP4, something that could be fixed by some hacks to Qt5 or other apps, but should rather be fixed in the driver (or user-level library stub). Best, Stephan On 20.11.2012, at 13:30, "Sundareson, Prabindh" <pr...@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....@qt-project.org > [mailto:interest-bounces+prabu=ti....@qt-project.org] On Behalf Of Stephan > Kanthak > Sent: Tuesday, November 20, 2012 1:32 PM > To: interest@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....@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
