AM35x/OMAP35x SGX graphics libraries hard float?

Hi Chase,

Thanks for the info and fast response! Just for future reference for anyone else, I followed the trail of git repositories and shell scripts from the link you provided and ended up with this direct link for the hardfloat user mode libraries/binaries:

http://rcn-ee.net/sgx/armhf/sgx-hardfp.tar.gz

The included README says the libraries have been compiled with Linaro GCC 4.6.3 with the following flags:

-march=armv7-a -mfloat-abi=hard -mfpu=neon

...which is exactly what I was looking for!

I haven't been able to test it yet (I'm running into another glibc incompatibility issue causing the message "../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed." to be printed), but this definitely looks like the real deal! Once I figure out that problem, I'll update this post to say whether everything works. The README says only the 5.x libraries have been tested, but I'll see if I can get the 3.x libraries working on the AM3517 Craneboard.

Update: I got past the problem I mentioned above by upgrading my eglibc from 2.13 to 2.16. I guess I had too old of a version -- anyway, the demo programs seem to be working fine now, so I think everything is good!

Thanks again,
Doug

Good to see that you have been able to use the hardfloat binaries. Can you also let us know:

- What is the resolution of your screen ?

- What Linux kernel version and filesystem you have tested this with ?

- Are there any windowing systems (other than linuxfb) that you are testing this with ?

Hi Prabindh,

I'm working with a 720x482 resolution over HDMI, and I've also tested with 1024x768. I have my own custom root filesystem built from scratch. My C library was compiled with crosstool-NG, set for:

• binutils 2.21.1a
• gcc 4.6.3
• eglibc 2.16

I'm also using busybox. The kernel is 2.6.37 from the Linux PSP version 04.02.00.07, with a few patches to the NAND driver and adding Craneboard support.

I'm only using it with linuxfb right now, but I plan on trying it with Qt if I can get it all to compile and play nice.

The only demos (except for the X stuff which I can't use because I'm not using X) that I haven't been able to get to work are the ews_* demos (they didn't work for me on the softfloat binaries either, though, so it's not a hardfloat problem from what I can tell). ews_server and ews_server_es2 both print out:

EWS: Fatal error: eglGetDisplay
EWS:    (in pm_thread_main at pm.c line 315)
Aborted

Here's the output of the gfx_check script in case you're interested:

WSEGL settings
[default]
WindowSystem=libpvrPVR2D_FRONTWSEGL.so
#WindowSystem=libpvrPVR2D_FLIPWSEGL.so
ParamBufferSize=16777216
------
ARM CPU information
Processor       : ARMv7 Processor rev 7 (v7l)
BogoMIPS        : 501.02
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0xc08
CPU revision    : 7

Hardware        : AM3517/05 CRANEBOARD
Revision        : 0020
Serial          : 0000000000000000
------
SGX driver information
Version CustomerTI_OMAP4430_Linux_GPL sgxddk 17 1.7@867897 (release) /home/doug/Downloads/Craneboard/SGX/Graphics_SDK_4_06_00_02/GFX_Linux_KM
System Version String: SGX revision = 1.2.1
------
Framebuffer settings
------
Rotation settings
0
------
Kernel Module information
bc_example 6592 0 - Live 0xbf047000
omaplfb 12095 0 - Live 0xbf037000
pvrsrvkm 162834 2 bc_example,omaplfb, Live 0xbf000000
------
Boot settings
console=ttyO2,115200n8 root=/dev/nfs nfsroot=/sgxroot ro rootfstype=nfs eth=80:02:8e:c3:db: ip=192.168.1.249:192.168.1.122:192.168.1.1:255.255.255.0::eth0:off omapfb.mode=dvi:1024x768MR-16@60 vram=24M omapfb.vram=0:20M earlyprintk omap_vout.video2_bufsize=4153344 omap_vout.video1_bufsize=4153344
------
Linux Kernel version
Linux CRANE2 2.6.37 #64 Wed Jul 18 09:16:00 PDT 2012 armv7l GNU/Linux

(fbset in busybox seems to not support the -i flag, so that's why the output is blank)

Just a little more info on this...I have now been able to test the hardfloat SGX libraries with Qt Embedded and everything appears to be working fine on both the HDMI output and the TV output. This is with Qt 4.7.4 patched with the WSEGL2 patch on this page and configured for OpenGL ES 2.

The deform demo shows some bars of color in the background when I enable OpenGL -- not sure if this is weird behavior or normal. I'm assuming normal? The hellogl_es2 demo seems fine. Running with the powervr screen driver shows noticeable performance improvement even with a program that does its drawing with ordinary QWidgets, so that's a nice surprise.

Just a few notes about getting it running:

• If you're using 24-bit color (RGB 8/8/8) you must enable the alpha channel as well in the framebuffer (so you are in ARGB 8/8/8/8 mode). busybox's fbset won't set it correctly but you can do it manually with your own program or use a more complete version of fbset.
• One of the include paths relative to the Graphics SDK root in the supplied Linux-TIarmv7-sgx-g++.tar.gz file was wrong, so Qt failed to compile until I made it point to the correct headers by adding this line:

• QMAKE_INCDIR_OPENGL_ES2 += $$SGX_SDK_ROOT/include/OGLES

• Don't forget to update /etc/powervr.ini as directed in the wiki and run your program either:

• with the -display powervr option, or
• with the QWS_DISPLAY environment variable set correctly for powervr instead of linuxfb

Hi Doug,

I'm reading up on the use of the SGX as fast as I can but there bits I haven't found yet. We have a Qt app running on AM3715, it's a busy button/menu GUI. Do you think we will see improvements by pulling in OpenGL and the required modules without re-writing the app? (Your comment "Running with the powervr screen driver shows noticeable performance improvement even with a program that does its drawing with ordinary QWidgets, so that's a nice surprise." )

  Ben

Hey Ben,

I don't know for sure about your particular program, but it's probably worth a try. In my program, I have a big widget that draws a lot of things (lines, rectangles, text, and pixmaps) and handles dragging them around on a touchscreen. If I run the program with the standard LinuxFb driver, the dragging can be pretty jerky. When I run it with the PowerVR driver, the dragging is smooth -- it appears that the painting is being accelerated in some way (I don't know exactly what part of it is accelerated though). It's all just a standard QWidget subclass.

There is a major drawback I have run into though -- it doesn't behave nicely if I try to run another program under its qws instance (i.e. running another program without the -qws option so it uses the original program run with -qws as its window manager). The second program segfaults. This isn't a big deal for me, but I would imagine for some people that might be a problem.

Edit: Actually, nevermind -- the segfault is some other issue with a program I wrote that crops up regardless of whether I'm using PowerVR or not. Looks like multiple programs run fine with the PowerVR driver after some limited testing.

Doug

For more information on what gets accelerated in Qt when powervr is used, refer to below link,

http://processors.wiki.ti.com/index.php/XgxPerf_HMI#Using_Qt.27s_Powervr_backend_for_display.2F_3D_acceleration_in_XgxPerf

Many thanks Doug for your experience on this. I'm going to give it a try.

Thanks for the documention on this Prabindh, it looks like it's worth a try.

  Ben

After various delays I've had a chance to spend time on this. After quite a bit of work I got QT compiling with the configure options for OpenGL2, and the SGX_SDK compiling OK and installed on the target. omap-demo runs and installs the required modules: lsmod shows omaplfb and pvrsrvkm
I can run /gfxlibraries/gfx_rel_es5.x/ demos:
services_test
sgx_blit_test
pvr2d_test
I can run /gfxsdkdemos/ogles2/  OGLES2Coverflow,  OGLES2Shaders etc.

however if I run an app with the -qws -display powervr options I get
powervr: driver not found

I've checked that both libpvrQWSWSEGL.so and libqgfxpvregl.so are present. I've exported QT_PLUGIN_PATH (to my lib dir where all the QT stuff is), and LD_LIBRARY_PATH to include all the lib dirs and the gfxlibraries dir.

Any clues?

Hey Ben,

It looks to me like your Qt doesn't know about powervr at all. For example if I start with -display blah, it says the same thing about "blah". I think if you had an LD_LIBRARY_PATH problem or something like that it would get further than that error message. What is the command you used to configure Qt? Did you verify that it said powervr support would be included at the end of the configuration when it displayed a summary of all selected options?

Another thing to try might be to run your program using strace to see what Qt is doing as far as system calls go. It will show you what files Qt is trying to open as you launch the program. It might give you a clue about what is causing it to fail.

Doug

Please check below link, post the logs as described:

http://processors.wiki.ti.com/index.php/SGXDbg#Qt.2FE_demos_do_not_work_when_powerVR_is_enabled

Many thanks Doug. Will check that out.

Enclosed is the results of the sgxperf_check.sh4152.SGXperf.txt

My QT configure setup is:

./configure -embedded -nomake demos -nomake docs -nomake translations -opengl es2 -plugin-gfx-powervr -platform qws/linux-x86-g++ -xplatform qws/linux-arm-g++ -depths 16,24,32 -exceptions -no-multimedia -no-mmx -no-sse -no-sse2 -no-3dnow -no-cups -no-openssl -no-dbus -no-glib -no-openssl -no-nis -no-qt3support -no-xmlpatterns -no-libmng -no-pch -no-libtiff -no-largefile -no-openssl -qt-mouse-pc -qt-mouse-linuxtp -qt-mouse-linuxinput -plugin-mouse-linuxtp -plugin-mouse-pc -opensource -qt-mouse-tslib -L $root/target/tslib/_build/lib/ts/ -I $root/target/tslib/_build/include/ -L $root/target/tslib/_build/lib/ -L $root/target/fs/root/opt/gfxlibraries/gfx_rel_es5.x -no-webkit -ldl -prefix /

Need the terminal log, with QT_DEBUG_PLUGINS set to 1.

I observe that you are on a very old kernel, and very old driver set.

Noted on the versions, this is the very last thing to do on a multiple product range which started out on these releases. I don't want to have to redo these versions now if at all possible.

I'm compiling in release mode only at present as this was the only way to get "-embedded arm" to work. I'll have a look at changing the configuration and running the debug.

THanks.

Actually the release only build is another thread I'm working on - so -release is not set and I don't see anything when I do export QT_DEBUG_PLUGINS=1 and the run the app. IS that how you set this environment variable? I haven't come across it before?

It should work even in release mode. As an example, I run my program like this:

QT_DEBUG_PLUGINS=1 /testapp -qws

And I get some info showing various plugins being loaded by QFactoryLoader. Aside from powervr, it also loads plugins for various image formats. If you're not getting any output, maybe that means no plugins are being loaded.

To be fair, I keep everything in the same directory on my host and target (/usr/local/Trolltech/....) so I don't need to set any environment variables for the plugins. I'm not sure how to get that set up correctly in a different scenario.

Thanks Doug.

I still get no output, whether with powervr or not (without powervr my app runs as normal without the GSX boost). I'll see if I can get strace to produce something.

Well, by adding a /plugins/gfxdrivers folder and export QT_PLUGINS_PATH=/......  rather than relying on a flat folder stucture, powervr is found!

But, the display is then reported as being the wrong format. i.e. RGB8888 needed.

I try "fbset -rgba 8/16,8/8,8/0,8/24" but this has no effect, so I install fbset 2.1. 
tigraphics.blogspot.co.uk/2011/07/running-qtgles-on-omap4.html

Now fbset works - and my app with -display powervr runs!!!

It's upside down and the wrong size, but we're nearly there! (my bootargs were using omapfb.rotate=2 , perhaps this no longer works)
Thanks for all your help Doug and Prabindh.

Hey Ben,

Glad you got it mostly working! I ran into the same difficulty with the frame buffer. It's because busybox's fbset doesn't support setting the alpha bits. Looks like you got that part figured out.

Just out of curiosity, are you seeing better graphics performance?

BTW, just so everyone knows, the newest TI Graphics SDK is available with hardfloat libraries now too. I haven't tested the new libraries out yet though.

Doug

Did you use fbset to change the display settings or modify them in uboot somewhere in the end?

My screen is now half the height and upside-down. I presume the height difference is down to the 24bit to 32 bit change not being complete. Is there an equivalent of bootargs omapfb.rotate to rotate the display with powervr? (fbset is reporting the correct dimensions)

As the display is smaller and the touchscreen is difficult to use with the display upside-down(!!) I'm not certain yet, but I think screen scrolling is smoother.

I wrote my own program that does the same thing as fbset -- it just manually sets the framebuffer depth using the FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO ioctls inside of Linux. I don't do any screen rotation because it comes out correctly with no rotation by default.

Did you set the correct screen resolution and frame buffer depth prior to loading the PowerVR kernel modules? I believe weird things happen if you change the frame buffer after the kernel modules have loaded. I do it all before loading the PowerVR driver, or if I'm going to change it I temporarily remove the kernel modules, change the frame buffer, then redo the PowerVR initialization sequence that loads the kernel modules and calls pvrsrvinit.

Also, is it possible that maybe you don't have enough VRAM allocated now that you've added the extra 8 bits per pixel? For example, you could add this to your bootargs:

vram=24M

You probably don't need 24 MB, but that's just an example. Just a couple of ideas to try...

Removing the old omapfb parameters from the bootargs got the screen size back to normal. Now, how do you rotate with PowerVR?

I'm getting more sceptical about speed benefits now that it's the right size .... hmmmm.

Seems like you do use the omapfb to rotate, but there's a bug in it.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/40394/149000.aspx#149000

My rotation is 180 deg so the simple patch above doesn't help.
In view of the lack of visible performance improvement and lack of project time, I might have to leave this exploration now.

Thanks for your help Doug.