Hi Prabindh, first hand info, that's very well appreciated :-)
Am 16.11.2012 um 05:29 schrieb "Sundareson, Prabindh" <pr...@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@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....@qt-project.org > [mailto:interest-bounces+prabu=ti....@qt-project.org] On Behalf Of Stephan > Kanthak > Sent: Thursday, November 15, 2012 3:37 PM > To: interest@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@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
