Building Qt to make use of the Beagle board’s SGX GPU

Published Friday November 20th, 2009
32 Comments on Building Qt to make use of the Beagle board’s SGX GPU
Posted in Build system, Embedded, Graphics View, OpenGL, Painting, Performance, Qt

Introduction

Texas Instruments has a wiki which documents what is required to bring Qt
up on the Beagle board with full OpenGL ES (1/2) support:

http://www.tiexpressdsp.com/index.php/Building_Qt

and I would like to thank one of their engineers, Varun, for his quick turn
around times in addressing any questions I raised.

This blog entry is intended to serve a similar purpose, but is more verbose regarding
Qt considerations and the initial beagle board bring up. It attempts to serve
as a comprehensive independent source of information on getting Qt built
for the Beagle board with full OpenGL ES 2 support.

These instructions are intended for use with Qt 4.6 (and beyond), so grab
the release candidate or check Qt 4.6 out from the public git repository prior
to proceeding.

You can choose to use either Qt/Embedded or Qt/X11, both can
be successfully integrated with the Beagle board’s SGX GPU and the only
point of divergence in these instructions will be at (Qt) configure time
and the client side system (run time) configuration. Both implementations
offer window management, via QWS and X11 respectively, and operate at
around 27fps and 22fps respectively when running our hellogl_es2 example.
(16bit color depth at 1280×720)

I personally deploy Ångström on my Beagle board, it handles a large amount
of the logistics surrounding cross compilation and is generally very
agreeable, and these instructions are therefore going to be bolted to
Ångström for completeness. Feel free to establish an environment capable of
showing the OpenGL ES examples TI provide, then following the Qt level
considerations (Configuring Qt) accordingly.

For those holding a dormant Beagle board who are open to the author’s
distribution preferences:

Building the Ångström rootfs

Open Embedded is manifested in a git repository: in this posting we are
working within origin/stable/2009. Please follow the instructions give
here, they are comprehensive and got me completely off the ground.

http://www.angstrom-distribution.org/building-angstrom

These instructions end in you running:

bitbake base-image ; bitbake console-image ; bitbake x11-image

which actually builds an X11 angstrom image for your Beagle board. Please
note, you will need to build the X11-image if you want to build and deploy
the SGX packages (we will do this in the next section) via Ångström as opkg considers
X11 to be a required dependency of libgles-omap3_3.00.00.09. This is due
to one of the encapsulated windowing system libraries being X11 centric:

libpvrPVR2D_X11WSEGL.so

Regardless of the indicated X11 dependency, this package will bestow the required
kernel module on you for general OpenGL ES usage (console or X11). We will be
building our own QWS centric (libpvrPVR2D_X11WSEGL.so equivalent) library
behind the scenes for QWS in the Qt/Embedded instructions given later.

Ångström SGX integration

You now need to integrate the SGX drivers on your Ångström system.

You need to get your paws on:

OMAP35x_Graphics_SDK_setuplinux_3_00_00_09.bin

with the following MD5 checksum:

e15147ad76ddbe7c5aec682f5455b774

Getting this involves following the above link and going through the required registration/request process.
Once you have this file, you drop it in:

$OETREE/openembedded/recipes/powervr-drivers/libgles-omap3

and then run:

bitbake libgles-omap3-3.00.00.09

which generates the following packages:

libgles-omap3_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-dbg_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-demos_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-dev_3.00.00.09-r1.1_armv7a.ipk
libgles-omap3-tests_3.00.00.09-r1.1_armv7a.ipk

Deploy the x11-image to an sd-card, and copy these packages to the sd-card
for deployment on the target. If your beagle board does not have internet
access you will probably also require:

*  devmem2
*  libx11-6 (Only if you insisted on using a console build!)

as opkg will not be able to automatically install the required dependencies
from its repositories and you would hit the following error at deployment:

———————————————-
root@beagleboard:/opt/deploy# opkg install ./libgles-omap3_3.00.00.09-r1.1_armv7 a.ipk
Installing libgles-omap3 (3.00.00.09-r1.1) to root…
libgles-omap3: unsatisfied recommendation for libgles-omap3-tests
Collected errors:
* ERROR: Cannot satisfy the following dependencies for libgles-omap3:
*  devmem2 *  libx11-6 (>= 1.1.5) *
———————————————-

Once you have installed all the above packages, please reboot the board.

Your bootargs in U-Boot should look something like:

console=ttyS0,115200n8=noinitrd ip=dhcp rw root=/dev/mmcblk0p2 omapfb.mode=dvi:1280x720MR-16@60

assuming you want to output via DVI and are running a similar kernel
version (2.6.29-omap1 on my beagle) which accepts the same kernel
arguments indicated in the bootargs variable above.

Please note that we are specifying a 16 bit color depth which is intentional
and discussed in the “color depth considerations” section in the appendix

Please run the powervr demos (under X11) to establish that your drivers are
successfully installed and usable.

Configuring Qt

In order to build Qt now, all that is required for each target is an
appropriate mkspec:

For Qt/X11

You would fork your mkspec off the linux-g++ mkspec, the resulting mkspec’s
qmake.conf would resemble:

==================================================================
………….
include(../common/linux.conf)

# modifications to g++.conf
# These release optimization flags are TI supplied
# and a little more aggressive than Qt standard (gentoo types rejoice!)
QMAKE_CFLAGS_RELEASE     = -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
QMAKE_CXXFLAGS_RELEASE     = $$QMAKE_CFLAGS_RELEASE

QMAKE_CC         = $FULLY_QUALIFIED_COMPILER_PREFIX-gcc
QMAKE_CXX         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK_SHLIB     = $FULLY_QUALIFIED_COMPILER_PREFIX-g++

# modifications to linux.conf
QMAKE_LIBS_EGL         = -lEGL -lIMGegl -lsrv_um
QMAKE_LIBS_OPENGL_QT     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um
QMAKE_LIBS_OPENVG     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um -lOpenVG -lOpenVGU

QMAKE_INCDIR         = $TARGET_STAGING_PATH/usr/include
QMAKE_LIBDIR         = $TARGET_STAGING_PATH/usr/lib

QMAKE_AR         = $FULLY_QUALIFIED_COMPILER_PREFIX-ar cqs
QMAKE_OBJCOPY         = $FULLY_QUALIFIED_COMPILER_PREFIX-objcopy
QMAKE_STRIP         = $FULLY_QUALIFIED_COMPILER_PREFIX-strip

load(qt_config)
==================================================================

and you would configure Qt with:

configure -arch arm -xplatform linux-omap3-g++ -opengl es2 -openvg

all that remains is to adjust /etc/powervr.ini on the target to be:

[default]
WindowSystem=libpvrPVR2D_FLIPWSEGL.so

Now compile an example, eg:

./examples/opengl/hellogl_es2

deploy it and Qt to the target and enjoy.

For Qt/Embedded

Since we don’t have the X11 abstraction, we have to interface with the
underlying hardware/interfaces with Qt/Embedded’s gfx abstraction layer. We
are going to be making some heavy use of the powervr driver resident under:

$QTSRCTREE/src/plugins/gfxdrivers/powervr

there is a README file in the powervr directory that is definitely
recommend reading, and lends some serious insight into our powervr driver
and Qt/Embedded in general. The same driver is used for MBX/SGX targets and
hence sees a fair amount of usage on a variety of target devices.

You would fork your mkspec off the qws/linux-arm-g++ mkspec, the resulting mkspec’s
qmake.conf would resemble:

==================================================================
…………….
include(../../common/qws.conf)

# modifications to g++.conf
QMAKE_CFLAGS_RELEASE     = -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
QMAKE_CXXFLAGS_RELEASE     = $$QMAKE_CFLAGS_RELEASE

QMAKE_CC         = $FULLY_QUALIFIED_COMPILER_PREFIX-gcc
QMAKE_CXX         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK         = $FULLY_QUALIFIED_COMPILER_PREFIX-g++
QMAKE_LINK_SHLIB     = $FULLY_QUALIFIED_COMPILER_PREFIX-g++

# modifications to linux.conf
QMAKE_INCDIR         = $TARGET_STAGING_PATH/usr/include
QMAKE_LIBDIR         = $TARGET_STAGING_PATH/usr/lib

QMAKE_LIBS_EGL         = -lEGL -lIMGegl -lsrv_um
QMAKE_LIBS_OPENGL_QT     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um
QMAKE_LIBS_OPENVG     = -lEGL -lGLESv2 -lGLES_CM -lIMGegl -lsrv_um -lOpenVG -lOpenVGU

QMAKE_AR         = $FULLY_QUALIFIED_COMPILER_PREFIX-ar cqs
QMAKE_OBJCOPY         = $FULLY_QUALIFIED_COMPILER_PREFIX-objcopy
QMAKE_STRIP         = $FULLY_QUALIFIED_COMPILER_PREFIX-strip

#These defines are documented in the powervr README, please read it
DEFINES += QT_QWS_CLIENTBLIT QT_NO_QWS_CURSOR

load(qt_config)
==================================================================

and you would configure Qt with:

/opt/dev/source/qt-beagle-4.6/configure -embedded arm -little-endian -xplatform qws/linux-omap3-g++ -opengl es2 -openvg -plugin-gfx-powervr

all that remains is to adjust /etc/powervr.ini on the target to be:

[default]
WindowSystem=libpvrQWSWSEGL.so

Now compile an example, eg:

./examples/opengl/hellogl_es2

deploy it and Qt to your board, and after shutting down X, run the example with
the following arguments:

./hellogl_es2 -qws -display powervr

-qws – starts the application as the QWS server with exclusive access to the
system hardware which manages all subsequent Qt “client” applications

-display powervr – indicates that Qt should use the powervr driver we
compiled earlier

Summary

I hope that this posting encourages people to go forward and experiment
with a fully accelerated Qt 4.6 on the beagle board. Offloading the
painting work onto the GPU drastically reduces the load on the CPU and
broadens the range of applications which can feasibly be run on this
broadly available (cheap!) embedded hardware. The Beagle board has
really nice hardware, and it would be infinitely useful for us to have external
people using our powervr driver and getting it as broadly used/refined as
possible.

Appendix

Additional Benefits to OpenGL ES acceleration

If you take any Qt Graphics View based example and set a QGLWidget as its
viewport, a large amount of work will be offloaded on the GPU leaving your
CPU free to frolic. To put this in perspective, a modified version of:

./examples/animation/animatedtiles

which continually transitions runs smoothly at 720p on the beagle board
when using software, but consumes 100% CPU time according to top (99.3% to
be fair). It is therefore CPU bound and you are not going to be doing
anything else in the background.

When backed by a QGLWidget, the CPU usage drops to 20% on the exact same
example in the exact same conditions (720p, at 16bit color depth). The
frame rate suffers slightly, but at least this is mandated by the GPU

Minor clipping issue evident in hellogl_es2

The bubbles are evidently clipped on the right hand side, I will hopefully
beat you to reporting this at: http://bugreports.qt.nokia.com/secure/Dashboard.jspa

I have not seen any other artifacts, please file any additional bugs you
may encounter at the above URL.

Are these instructions applicable to OMAP3 targets in general

Yes. There is no theoretical reason these instructions would not suffice
for any OMAP3 based target, although I have not personally verified them
outside of Beagle board usage. Caveat emptor.

No Scratchbox2 usage when cross compiling

The more astute of your would recognize that I bypassed Scratchbox2 when
configuring Qt/X11 this time around. I payed dearly for it, and this X11
build has no fontconfig, dbus or glib support even though the Ångström
subsystem I am building against has support for all of them. If you want a
full fledged X11 build with decent font support and OpenGL ES support,
please either:

1) Invest your time in physically adjusting your MKSPEC (and/or wrestling
pkg-config) to get all desired dependencies detected and built against

-Or-

2) Take the easy road, refer to my previous blog posting “Cross compiling
Qt/X11” and merge the above mkspec changes into the:

./mkspecs/unsupported/linux-scratchbox2-g++

mkspec in your Qt 4.6 source tree.

The same goes for Qt/Embedded which is more self sufficient, but which will
be built without dbus, glib, etc and additional external dependency support
without additional mkspec/environment modification or the use of Scratchbox2
to abstract this away.

Color depth considerations

1) The powervr implementation we are relying on does not support
PVRSRV_PIXEL_FORMAT_RGB888 (24bit color depths), it does however support
PVRSRV_PIXEL_FORMAT_RGB565 and PVRSRV_PIXEL_FORMAT_ARGB8888

2) Ångström is busybox based, and the fbset command you will need to set 32
bit color depths on the console will not work with the default fbset
busybox symlink. You will therefore have to install and use fbset(.real)
in order to get 32bit color depths, which is a simple opkg install away for
the connected Beagle board and a bitbake away for the stranded.

Please note the color depth specified in the boot arguments

console=ttyS0,115200n8=noinitrd ip=dhcp rw root=/dev/mmcblk0p2 omapfb.mode=dvi:1280x720MR-16@60

if you want 32 bit color depth, use:

console=ttyS0,115200n8=noinitrd ip=dhcp rw root=/dev/mmcblk0p2 omapfb.mode=dvi:1280x720MR-24@60

followed by:

/usr/sbin/fbset.real -depth 32 -rgba 8/16,8/8,8/0,8/24

after your Linux kernel drops you in userspace with a kiss on the cheek. A
brave man once tried leaving the color depth at 16 in his boot args, and
jumping all the way to 32bit with fbset so he could change between the more
performant 16 bit color space and the hardware compositing ARGB offering.
Running the dedicated fbset command halved his vertical resolution
regardless of any other parameters he tried to pass fbset and he eventually
ran off to fight another day.

There is a clear performance hit of 7 fps when running hellogl_es2 in
32bit rather than 16bit, taking you down to 20 fps. This hit is even more
pronounced when setting a QGLWidget on the viewport of a QGraphicsView. I
am not sure who is responsible for this, and will be personally
investigating it in the future. Any conjecture/feedback/research performed
by the reader would be greatly appreciated.

*Edited: Introduce rudimentary formatting to make the blog look less Vim forged

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Build system, Embedded, Graphics View, OpenGL, Painting, Performance, Qt

32 comments

Giovanni Bajo says:

Impressive… does this also mean that a standard GUI program executed with “-graphicssystem opengl” will have its painting code for all widgets offloaded to the GPU through OpenGL ES?

Koen says:

Please note that there is already an openembedded recipe to build qt/e against the sgx sdk, you just need to do:

mv recipes/qt4/qt4-embedded-gles_4.5.2.bb.disabled recipes/qt4/qt4-embedded-gles_4.5.2.bb ; bitbake -c clean qt4-embedded ; bitbake qt4-embedded-gles

And after it finishes building then you’ll have the qtopengl lib and the graphics system plugin.

If you have already installed the libgles-omap3 package you can just do

opkg install qt4-embedded-plugin-gfxdriver-gfxpvregl

Since the angstrom feeds already have prebuilt packages for you 🙂

AndyN says:

Using pkg-config pretty easy to set up:
Set the environment variables:

export PKG_CONFIG_PATH=$TARGET_STAGING_PATH/usr/lib/pkgconfig
export PKG_CONFIG_SYSROOT=$TARGET_STAGING_PATH/

Append the configure argument: -force-pkg-config

Now you have fontconfig, dbus and glib support without the painful configuration of the mkspec

Donald Carr says:

@Giovanni

Yes, theoretically and to the best of our ability. If you have sane GL enabled hardware there will definitely be some offloading, although the painting overhead is not entirely removed from the CPU and your results will vary with the nature of your application. QGraphicsView based applications which are blit/scale intensive are very conducive to offloading, hence the 100% -> 20% CPU usage jump we see above.

My primary exposure to our QPainter backend acceleration is via the QWS DirectFB driver plugin, where using it results in:

1) QPixmap being backed by a native DirectFB pixmap and being created in video memory
2) Certain Qt painter API calls backing directly onto the DirectFB API (where possible), and the rest falling back (verbosely if desired) on the Qt raster engine. This is enough to see substantial improvements in painting performance on CPU constrained devices, although the accelerated operations need to be borne in mind when adding bling to your application.

@Koen

Thanks for raising this: I saw the Open Embedded Qt recipes and generally enjoyed the abstraction provided by the platform. Qt 4.5 is all they offer there at present and is looking a little long in the tooth these days with the none too distant arrival of Qt 4.6. If that qt4-embedded-gles package works there must be some substantial modifications to the Qt 4.5 powervr driver (since SGX support was broken in 4.5), and part of the hope of this blog entry was to get people using the latest (common) code base and getting it into general public usage. Qt/Embedded (and our powervr support) would benefit heavily from some community attention.

@AndyN:

Again a valid point, deserving of an additional Caveat Emptor all for itself. There were 2 reasons why I opted for Scratchbox2 in my original post:

1) Our configure script often made flat assumptions about the location of certain libraries and header files and did not query pkg-config for every appropriate dependency (which has largely been addressed)
2) I have personally dealt with pkg-config versions which don’t give a hoot about your PKG_CONFIG_SYSROOT environment variable and are very non cross-compiler friendly (these versions were arguably broken, and there is as much likelihood of getting a broken Scratchbox2 package)

I do agree though, the pkg-config tool alone should suffice in these circumstances

Donald Carr says:

@Giovanni

Whoa, sorry just saw the phrasing of your comment.

Impressive… does this also mean that a standard GUI program executed with “-graphicssystem opengl” will have its painting code for all widgets offloaded to the GPU through OpenGL ES?

Yes, there will be offloading, this will facilitated through OpenGL or OpenGL ES depending on the OpenGL version Qt is compiled against. (Always OpenGL ES in my blog entry above, regardless of whether it is Qt/X11 or Qt/Embedded)

TomCooksey says:

I’m fairly sure “-graphicssystem opengl” will only work on the Qt/X11 flavor. To use the SGX for painting under Qt/Embedded (where -graphicssystem opengl has no effect), you must use QGLWidget: Either inherit from QGLWidget (rather than QWidget) or, if using graphics view, set a QGLWidget as the viewport. Of course you’ll always be using the SGX when rendering into a QGLFramebufferObject or QGLPixelBuffer (if supported?) too.

Tip: If you don’t care about anti-aliasing, set the default QGLFormat to one without sample buffers. This can give up to 20% extra fps.

Donnald: 32bpp is slower than 16 bpp simply because it requires twice the memory bandwidth, which is somewhat limited on the OMAP3.

ezjd says:

Qt with OpenGL for embedded and for X11 should be different. In Qt/Embedded, Qt with OpenGL talks to GPU accelerated openGL lib while in X11, Qt either talks to GLX, which passes OpenGL commands to X server, or talks to DRI (I think in this case the former applies). In either case, a GPU accelerated X/DRI driver is needed besides a OpenGL lib in Qt/Embedded case, however, in GLX case, the rendering happens in Xserver.

Because of GLX/DRI, overhead is added, and this can explain performance loss in Qt/X11 with OpenGL.

pundiramit says:

I have seen that exporting QT_PAINT_FALLBACK_OVERLAY against a debug build of Qt can detect the Qt/X11 with ‘-graphicssystem opengl’ fallback to native/raster paint engine. Will it work for openvg backend too?
Or is there any way I can confirm that Qt/X11 with ‘-graphicssystem openvg’ is not falling back to native/raster paint engine for unsupported(or even supported) features?

Donald Carr says:

Another heads up:

My beagle board is revision C3, I was having no joy adjusting color depth via bootargs, and realized that mmcargs was obliterating my efforts.

U-Boot uses a fairly straight forwards scripting language, I did not bother tracing through it to fully confirm my suspicions, I simply obliterated mmcargs (which explicitly sets boot args (over your personal efforts)) and suddenly my boot args level settings were being respected.

This is vitally important as the boot args set by mmcargs leaves your Beagle board with a 24bit color depth, which sets you up for the fbset pain and torment documented (and worked around) above in the color depth appendix.

Tom says:

@ezjd: We’re talking about Qt/X11 running on the BeagleBoard here, not Qt/X11 running on a desktop OpenGL implementation based on DRI1. Everything you said only applies to such desktop GL drivers and thus does not apply to the BeagleBoard.

The difference in performance between X11 & QWS is due to the differences between the WSEGL plugin for X11 & QWS.

ezjd says:

@Tom: Thx for pointing out this. I admit that I don’t know much about beagle board so my knowledge is based on general information.
My understanding is that this WSEGL plugin for X11 provides some kind of direct openGL rendering similar to DRI. Does it provide standard OpenGL API? I think it is as I assmue Qt OpenGL support is based on OpenGL ES API.
As it doesn’t have GLX or DRI support, I guess the X11 can’t have HW openGL acceleration. I am just wondering if this approach can run openGL app within a window or full screen only. Thx.

Donald Carr says:

@AndyN: I just compiled Qt/X11 after exporting PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT appropriately and concede that pkg-config alone gets you where you would want to be when cross compiling Qt/X11 4.6 under Ubuntu 9.10. If you look at the implication of my previous suggested sb2 (scratchbox2) usage, it is effectively operating as an aggressive alternative to exporting PKG_CONFIG_SYSROOT, and hence warrants mentioning only as one possible work around when configure tests are mysteriously failing.

Thiago Macieira says:

PKG_CONFIG_SYSROOT_DIR is broken in the current pkg-config version (0.23).

You need to ensure that your version has the patch from upstream.

Donald Carr says:

@Thiago: ye gads, thanks for clarifying/drawing attention to this.

pkg-config 0.22-1build1 as shipped with Ubuntu 9.10 is functional enough to scratch all of Qt’s itches, although mind you, I exported both PKG_CONFIG_SYSROOT and PKG_CONFIG_SYSROOT_DIR to the same appropriate path in my Angstrom tree.

Have I mentioned that Scratchbox2 makes a lovely PKG_CONFIG_SYSROOT/PKG_CONFIG_SYSROOT_DIR replacement when dealing with a flaky pkg-config! (to clear up FUD, my prior blogged approach ran configure against the targets .pc files, and solely dropped into the sb2 sandbox whenever the (cross) compiler was invoked, using no target instruction (qemu) emulation at any point in the process)

Donald Carr says:

You will get optimal mileage on your QGLWidget backed QGraphicsView with the following configuration:

QGraphicsView view(&scene);
view.setViewport(new QGLWidget());
view.setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
view.setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
view.setViewportUpdateMode(QGraphicsView::FullViewportUpdate);
view.setFrameStyle(0);
view.showFullScreen();

Add content as you see fit

Chris Burke says:

@TomCooksey: I am noticing quite a bit of slowdown when switching from 16 bpp to 32 bpp. Do you know if there is some sort of upper limit to how much memory the omap board can be moving around? We have a 1024×768 @ 32bpp graphics view application moving around large portions of the screen. Also, has anyone been evaluating the qAlpha performance? When profiling my app with gprof, I was getting readings of 70% of cpu time being spent in qAlpha.

@Donald: Did you actually get GraphicsView examples to run correctly when using a QGLWidget? We have got them to run but we get the following issue: ftp://ftp.ics.com/drop/animatedtile_openGL.MOV

Donald Carr says:

@Chris: Sorry about the dramatic pause. Yes, I am making heavy use of QGLWidget fronted graphics views without any issues. I tend to use Qt/X11 while your video makes it very clear you are using Qt/Embedded. I also restrict my OpenGL ES usage to OpenGL ES 2 since this is where the lion share of effort is being expended by us. Are you using OpenGL ES 2? I have seen your issue before, although outside of the 3 month window my brain readily functions in and I suspect it was in the days where I was working on OpenGL ES 1 targets.

I wonder if you were getting burnt by:

http://bugreports.qt.nokia.com/browse/QTBUG-6913

which is due to a scissor clipping bug in GLES 1.3 drivers. If so, the QT_GL_NO_SCISSOR_TEST define would scratch your itch, as documented in the bug entry above

Donald Carr says:

The following defines need to be included in the mkspec I use:

DEFINES += QT_QWS_CLIENTBLIT QT_NO_QWS_CURSOR QT_GL_NO_SCISSOR_TEST QT_DEFAULT_TEXTURE_GLYPH_CACHE_WIDTH=1024

These perform the following functions:

QT_NO_QWS_CURSOR (Works around fullscreen update on every cursor move)
QT_GL_NO_SCISSOR_TEST (Works around a known bug in older SGX drivers which I have never personally encountered)
QT_DEFAULT_TEXTURE_GLYPH_CACHE_WIDTH=1024 (Works around text corruption issues stemming from an inability to resize glyph caches at runtime. Change the glyph cache to a suitable value for the locale you are targeting)

Scott says:

Since QT_NO_QWS_CURSOR is required during the configure for QWS, do you have any recommendations for showing the mouse cursor? It is the only thing I’m missing now.

Fabio says:

I am trying to build QT embedded for a console-image and so I modified the qmake.conf accordingly.
Previuosly I obtained QT from git using the stable/4.6 branch.

I configure QT

./configure -embedded arm -little-endian -xplatform qws/linux-omap3-g++ -opengl es2 -openvg -plugin-gfx-powervr

and than make fails here :

egl/qegl.cpp: In static member function ‘static EGLNativeDisplayType QEglContext::nativeDisplay()’:
egl/qegl.cpp:380: error: invalid conversion from ‘void*’ to ‘EGLNativeDisplayType’
make[1]: *** [.obj/release-shared-emb-arm/qegl.o] Error 1
make[1]: Leaving directory `/home/fabio/OE/QT/qt/src/gui’
make: *** [sub-gui-make_default-ordered] Error 2

Any suggestion??

mczhao says:

As mentioned by Scott, since QT_NO_QWS_CURSOR was defined, the qt applications can’t show mouse cursor, even in application without using OpenGL. Is there any workaround to resolve this problem.

Luca says:

I found in http://www.angstrom-distribution.org/narcissus/ is possible to make an angstrom image for beagleboard and download it.
In the section “Platform specific packages” you can select:
PowerVR SGX drivers for OMAP3
PowerVR SGX gfxdriver plugin for QT/embedded

It also supply as SDK for the created image.

I made the image and installed in the beagleboard successfully next, with the SDK I compiled QT4-4.6.3 but if I put “-opengl” in the configure and than “make” I get this error while compiling opengl:

/usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++ -c -pipe -fno-exceptions -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_OPENGL_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_NO_FREETYPE -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/qws/linux-arm-g++ -I. -I../../include/QtCore -I../../include/QtGui -I../../include -I../../include/QtOpenGL -I.rcc/release-shared-emb-arm -I../3rdparty/harfbuzz/src -I/usr/include -I.moc/release-shared-emb-arm -I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include -o .obj/release-shared-emb-arm/qgl.o qgl.cpp
In file included from ../../include/QtCore/qurl.h:1,
from ../../include/QtGui/private/../../../src/gui/text/qtextdocument_p.h:69,
from ../../include/QtGui/private/qtextdocument_p.h:1,
from ../../include/QtGui/private/../../../src/gui/text/qtextengine_p.h:70,
from ../../include/QtGui/private/qtextengine_p.h:1,
from ../../include/QtGui/private/../../../src/gui/text/qfontengine_p.h:60,
from ../../include/QtGui/private/qfontengine_p.h:1,
from gl2paintengineex/qpaintengineex_opengl2_p.h:63,
from qgl.cpp:71:
../../include/QtCore/../../src/corelib/io/qurl.h:69: error: expected identifier before numeric constant
../../include/QtCore/../../src/corelib/io/qurl.h:69: error: expected `}’ before numeric constant
../../include/QtCore/../../src/corelib/io/qurl.h:69: error: expected unqualified-id before numeric constant
../../include/QtCore/../../src/corelib/io/qurl.h:81: error: ‘FormattingOption’ was not declared in this scope
../../include/QtCore/../../src/corelib/io/qurl.h:81: error: template argument 1 is invalid
../../include/QtCore/../../src/corelib/io/qurl.h:81: error: invalid type in declaration before ‘;’ token
../../include/QtCore/../../src/corelib/io/qurl.h:83: error: expected unqualified-id before ‘)’ token
../../include/QtCore/../../src/corelib/io/qurl.h:87: error: expected unqualified-id before ‘const’
….
….

Isn’t it possible to compile opengl in this way?

Donald Carr says:

Hey Luca,

It should be possible. I personally built the angstrom env from source, so I have not personally dabbled with the narcissus image/sdk images. This build issue looks like a header is polluting your build environment, you can see that the include chain looks fairly innocuous.

Yep, someone is definitely defining enums in the targets headers and consequently stepping on our toes. None is actually defined in X11, as is a bunch of other headers. I have actually seen this before, although it was on the Tegra2 not the Beagleboard. Your egl.h, eglplatform.h or other EGL/OpenGL ES headers are probably including X11 headers, which define None and a bunch of other things we define.

You can either try explicitly undeffing those defines at the top of qurl.h (after the includes) or invest some time and shuffle around the offending code to not actually clash with our declarations.

Luca says:

Thanks Donald, tomorrow I’ll try your advice.

It would be great if I could use opengl in the beagle board without building whole Angstrom.

Luca says:

I found too much define that conflict.
There are a lot on None, Unsorted, GrayScale, Status ecc…
I tried to replace None with None2, and so on, on qt source but it’s too time expencive and I think that it’ll never end…

Do you think there is another way?

Donald Carr says:

@Scott:
@mczhao:

To the best of my understanding, we explicitly set QT_NO_QWS_CURSOR when using QWS as we are otherwise using a software cursor, which when combined with OpenGL’s lack of partial updates, results in a full screen update for every mouse move. So you can happily reenable the cursor by removing this define, but you will be punished by a ludicrous number of full screen updates, and might end up with a net negative performance gain in using the OpenGL paint engine. I would recommend benchmarking your application on the target regardless, and establishing what exactly the performance impact is.

The possible solutions are:

a) remove QT_NO_QWS_CURSOR define from the mkspec and benchmark the performance to establish you have not just tossed out the baby
b) Use a touch screen (very nice)
c) Use X11 and a hardware cursor (which may or may not work, TM).

@Luca

Qt is constrained by the limitations of the c++ language. If someone is polluting the global namespace upstream, you will not get a very agreeable beverage in your cup. I have passed through the valley of shadow, and 5 or so undeffs later I was through it. This is not a random break, all the defines you mention are standard X11 defines that I have personally garroted in the name of compilation. File a bug with the perps for including X11 headers in EGL/GL headers, for shame.

bibr says:

Fabulous blog, Donald. For those interested, the 3.01 drivers have a slightly different approach in angstrom; the readme is apparently being updated as I write this note. Instead of putting the .bin file inside the recipes dir, put it in your downloads dir (where your other downloaded files are, tmp/downloads for me). Then touch a file with the same name plus “.md5” in the same dir, so “touch OMAP_…..bin.md5”. Now the same bitbake recipe above will build the latest SGX drivers.

Luca says:

Hi, I’m here again…
I want tell you that it seems to compile the qt-4.5.3-embedded with opengl for beagleboard using angstrom and toolchain from http://www.angstrom-distribution.org/narcissus/ .
I haven’t yet tried opengl in the beagleboard but during qt library building I didn’t get the previous X11 header problem.

Next days I’ll tell you if it works…

Luca says:

Unfortunately qt4-4.5.3 compile with opengl support but if I try to compile some opengl demo (hellogl ecc…) I get a lot of undefined reference…

Luca says:

I correct me, now the demos compiles without problem.

So I confirm that opengl support for beagleBoard (with angstrom downloaded from http://www.angstrom-distribution.org/narcissus/) compile good only with QT 4.5.3.

I hope that next version of QT will compile good for BeagleBoard as 4.5.3.

Greetings from Ohio! I’m bored at work so I decided to check out your website on my iphone during lunch break. I love the information you provide here and can’t wait to take a
look when I get home. I’m surprised at how quick your blog loaded on my phone .. I’m not even using WIFI,
just 3G .. Anyhow, amazing site!

If you are going for most excellent contents like myself,
just visit this web page every day since it gives quality contents, thanks

Commenting closed.

Get started today with Qt Download now