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

Stephan Kanthak stylon at gmx.de
Fri Nov 16 07:58:57 CET 2012


Hi Prabindh,

first hand info, that's very well appreciated :-)

Am 16.11.2012 um 05:29 schrieb "Sundareson, Prabindh" <prabu at ti.com>:

>>> I couldn't use their latest drivers SDK
> (only OMAP3), but please ask TI that question why they stopped 
> delivering a driver SDK for their OMAP4 suddenly about a year ago.
> 
> I cannot really comment on why, but am glad you got it working even with that older release.

Don't ask for the little hassles I went through :-). I already tried to get something working from drivers released by linaro/ubuntu which are newer, but unfortunately there are missing pieces (the release seems to include files for xcb/dri only).

>>> From the TI demos I conclude that the driver seems to buffer,
> but don't always swap buffers correctly at VSYNC time
> 
> What Linux kernel version and package/distribution are you using ? If you can dump the environment log from script in below page, I can perhaps answer your VSYNC query:
> 
> http://processors.wiki.ti.com/index.php/SGXDbg#Baselining_the_current_SGX_driver_environment

Here you go:

WSEGL settings
[default]
#WindowSystem=libpvrPVR2D_FRONTWSEGL.so
#WindowSystem=libpvrPVR2D_FLIPWSEGL.so
WindowSystem=libpvrPVR2D_LINUXFBWSEGL.so
#WindowSystem=libpvrPVR2D_BLITWSEGL.so
------
ARM CPU information
Processor	: ARMv7 Processor rev 3 (v7l)
processor	: 0
BogoMIPS	: 599.13

processor	: 1
BogoMIPS	: 594.13

Features	: swp half thumb fastmult vfp edsp thumbee neon vfpv3 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0xc09
CPU revision	: 3

Hardware	: OMAP4430
Revision	: 0010
Serial		: 0000000000000000
------
SGX driver information
Version 1.6.16.4117 (release) /home/stylon/prj/system/Graphics_SDK_4_04_00_03/GFX_Linux_KM
System Version String: SGX revision = 1.2.0
------
Framebuffer settings
fbset: not found
------
Rotation settings
0
------
Kernel Module information
Module                  Size  Used by    Not tainted
bufferclass_ti          4712  0 
omaplfb                11507  0 
pvrsrvkm              145076  2 bufferclass_ti,omaplfb
------
Boot settings
quiet mem=456M at 0x80000000 init=/init vram=10M omapfb.vram=0:10M vyres=1800 omapfb.vyres=1800
------
Linux Kernel version
Linux localhost 2.6.35.7+ #47 SMP PREEMPT Tue Nov 6 23:12:37 CET 2012 armv7l GNU/Linux

Please note that the kernel is pretty similar to the one Amazon released. I could have moved to 3.x already, but wanted to stay a bit more stable first. It still contains a lot of Android stuff, although I don't use the original pvrsrvkm, but instead the recompiled one from the driver package.

> regards
> Prabindh

Thanks already & best,
Stephan


> -----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: Thursday, November 15, 2012 3:37 PM
> To: interest at qt-project.org
> Subject: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
> 
> Hi,
> 
> some background first: for some little project I'm planning to prototype 
> a custom UI. I got interested in Qt5, because of QML + Javascript. The 
> OMAP4 platform I use (a modified Kindle Fire, but very similar to the 
> Pandaboard) offers EGL/OGLES2 and I got some drivers running from TI 
> directly on LinuxFB without XCB. I couldn't use their latest drivers SDK 
> (only OMAP3), but please ask TI that question why they stopped 
> delivering a driver SDK for their OMAP4 suddenly about a year ago.
> 
> Qt5 compiles fine now against those drivers (see my previous post) and 
> demos/examples run. Since then I also got extension stuff, e.g. from
> 
>    http://qt.gitorious.org/qtplayground/scenegraph
> 
> to compile and run.
> 
> The EGL/OGLES2 demos from TI run smoothly, despite some little tearing 
> here and there. Only OGLES2Water seems to stutter about once a second, 
> but let's take that as an exception. The TI driver is also configured 
> for 4 buffers (!). There's a little tool provided that tells you how 
> many buffers it manages to allocate and depending on how much memory is 
> being reserved at boot time, I do see that it allocates also 1, 2, 3 
> buffers. From the TI demos I conclude that the driver seems to buffer, 
> but don't always swap buffers correctly at VSYNC time. Although with 
> some demos (e.g. OGLES2ChameleonMan) it's pretty hard to find any tearing.
> 
> Now here's my problem: with unmodified Qt5 I don't get *any* smooth 
> animation. As far as I understood Gunnar's blog posts at
> 
>    http://blog.qt.digia.com/blog/author/gunnar/
> 
> this should not happen with Qt5/eglfs, except maybe when I use 
> Javascript, block the main thread with something else or run processes 
> in the background. But none of the latter is the case. So, I digged a 
> bit deeper. Here's what I tried:
> 
> 1. according to Gunnar's post, Qt5 tries to predict animation states for 
> the time a buffer is being displayed. So, I tried to find out what 
> refresh rate Qt5 assumes and it's indeed hard-coded to 60Hz and not 
> being overloaded by eglfs (see qplatformscreen.cpp, eglfs should be 
> corrected to ask the driver for the display's refresh rate in my view). 
> The Kindle Fire does some strange pixel-clock initialization and at the 
> end seems to fall back to something very close to 50Hz. So, I changed 
> that in the code => but, no effect at all.
> 
> 2. I tried the stuff at http://qt.gitorious.org/qtplayground/scenegraph. 
> The examples in the animators/test directory I did run with qmlscene. By 
> default all of them are stuttering a lot, no matter wether it's the 
> RenderThread or MainThread animation. Surprisingly, this changes once I 
> hit the "Block" button. That starts an infinite javascript loop in the 
> main thread. All of a sudden the RenderThread animation is perfectly 
> smooth and the MainThread animation becomes sufficiently smooth, but 
> just not as perfect as the RenderThread animation. Surprisingly, the 
> process does not exceed 25% CPU even when running that Javascript loop, 
> but without it uses <10%. I would expect ~0% without (most animations 
> just update a single property) and 100% with that Javascript loop. 
> And... I would have expected the animations to be smooth without the 
> block loop and stuttering when it's running.
> 
> 3. I did a tiny prototype qml animation and that runs really perfectly 
> smooth using qmlscene on a MacBook Air (that's why we all love macs, 
> right :-) ). Running the same on my platform stutters like the stuff 
> from that playground scenegraph. Using RT objects and the Javascript 
> main thread blocker loop improves smoothness a little bit, but not 
> comparably as smooth as in the scenegraph demo.
> 
> If Gunnar is listening to this list: I've no idea what is going on here 
> :-). It actually behaves so much against all my predictions (except the 
> TI demos) that I'm a bit puzzled. But maybe we can find out why it 
> behaves so strange.
> 
> Qt5 is not mandatory for my little project, so I could move forward with 
> plain EGL/OGLES2, but using QML + Javascript would make things for me a 
> lot easier.
> 
> Thanks & best,
> Stephan
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest



More information about the Interest mailing list