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" <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
