We have enabled SGX Driver on our Beagle board. We had hoped this
could promote the performace of our system because there is so much
graphic work in our application. But so disappointed to see there is
no any perfomance improvement. I have checked to assue the SGX Driver
kernel module have been loader corretly. And I asked the guys in TI
and Imagination, they all said if SGX Driver is enabled, most of
graphic work will be done by SGX GPU. But this fact told us it doen't.
So is there any furthure work we need to do?
Thanks!
Heh, the response from TI and IMGtec is just *so* wrong on *so* many levels it isn't funny anymore.
regards,
Koen
To illustrate my point, here's a cairo-perf diff of Xsgx (the supposedly accelerated X server from imgtec) with the sgx drivers working and loaded and plain old Xorg with fbdev as backend:
http://dominion.thruhere.net/koen/OE/Xsgx-Xord.perfdiff.txt
The unaccelerated Xorg is more than 20 times faster than the Xsgx one in some areas!
regards,
Koen
If we want promote our system's performance, what can we do? Could you
give some advice?
Our application is QTE(4.4.3) application with heavy graphic work(2D).
And a mp3 decoder is also running.
Thanks!
There's a PowerVR driver in Qt/Embedded 4.5.0, but you need two extra
headers to build it, pvr2d.h & wsegl.h. Register your interest in
using Qt's PowerVR driver on this forum thread:
http://www.imgtec.com/forum/forum_posts.asp?TID=136
The new driver will provide QGLWidget. If you set the viewport of a
graphics view to a QGLWidget, all the rendering will be done using
OpenGL ES 2.0. Hopefully in 4.6 you'll be able to use the driver for
all rendering without needing a QGLWidget.
I got pvr2d.h but I can not get wsegl.h,:(. Anyone can give me
wsegl.h. I will appriciate him/her very much!
Where did you get pvr2d.h from?
Will there be a powervr driver in proper QT as well? I'd would be sweet if mythtv 0.22 can use the SGX via QGL 
regards,
Koen
If by "proper" you mean Qt/X11!!!!!!
...Then yes, Qt/X11 4.5.0 will have full EGL/OpenGL ES 2.0 support in
QGLWidget. (Just pass "-opengl es2" to configure).
I'm hoping to write a QGraphicsSystem which uses the GL ES 2.0 paint
engine for regular widget rendering but I'm not sure when that will be
(either in a 4.5 patch release or as a labs project or perhaps 4.6).
At the moment I'm trying to figure out how to do things like partial
updates (don't want to use eglSwapBuffers just for a blinking cursor)
and scrolling efficiently. A lot of which will depend on how the
ImgTec drivers are integrated with X.
Cheers,
Tom
I manage the development of the Graphics SDK and DDKs for TI's
OMAP35x processors and I would like to clear up some confusion
regarding supported APIs and the performance of the SGX core on these
devices. First of all, there is no single SGX driver. What we
provide are drivers for OpenGL ES 1.1, 2.0, OpenVG 1.1 and EGL. The
performance for each of these is very good and these are the first low-
power SoC devices in the industry to support OpenGL ES 2.0. This is
possible only because of the SGX core's advanced programmable shader
engine.
The performance of X11 is an entirely different matter. I'm not
certain how this has been implemented on the SGX, but I suspect it was
done through a legacy API called PVR2D. That API is not directly
supported on the SGX and therefore it is not a good choice for
accelerating simple 2D operations like BitBlts, etc. A better choice
would be to implement them using the Cortex-A8's NEON instruction set
extension or to use the system DMA.
For more information, please read the white paper I recently
published, "Introduction to Graphics Software Development for OMAP
2/3", available at:
http://focus.ti.com/general/docs/gencontent.tsp?contentId=47536
Regards, Clay
Clay,
I sent email several times to TI to acquire ES1.1 and OpenGLES 2.0 library for SGX. No response at all,
I got confused. I don't even get deny response. Is there anyway you can help me communicate and get these libraries? I bought beagleboard several months ago.
Regards,
Yi
The TI guys send me pvr2d.h but they didn't provide wsegl.h.:(. I have
sent several mails to them to get wsegl.h, but no response.
I can not download the document from this URL:
http://focus.ti.com/general/docs/gencontent.tsp?contentId=47536
Thank!
I can not download the document from this URL:
http://focus.ti.com/general/docs/gencontent.tsp?contentId=47536
Thank!
You need to login to the TI extranet/portal in order to download the
"Introduction to Graphics Software Development for OMAP 2/3" paper. It's
free to sign up for a password and every step can be done through the WEB
AFAIR...
I just checked the link and after logging in I have no problems accessing
the file - Give it a try...
Best regards
Søren
You probably need to register at http://my.ti.com/ first, then you can
download it.
Regards,
Matthieu.
I manage the development of the Graphics SDK and DDKs for TI's
OMAP35x processors and I would like to clear up some confusion
regarding supported APIs and the performance of the SGX core on these
devices. First of all, there is no single SGX driver. What we
provide are drivers for OpenGL ES 1.1, 2.0, OpenVG 1.1 and EGL. The
performance for each of these is very good
The EGL library shipped with the SDK looks at /etc/powervr.ini (eughhh
- it also uses CRLF line endings!) and dlopen's the specified WSEGL
plugin library, which is responsible for integrating with the window
system. The OMAP3 SDK (at least the one I've been working with) comes
with several WSEGL plugins: X11, flip, front & blit. The last three
are pseudo window systems, which only give you a single "window" - the
whole screen.
What we have done in QWS (Qt Window System) is implement our own WSEGL
library which is using pvr2d to blit the window's back buffer to the
frame-buffer (scan-out buffer). As a result, Qt's powervr plugin needs
both pvr2d.h and wsegl.h to build. These files, as far as I know, are
only available as part of the DDK.
The performance of X11 is an entirely different matter. I'm not
certain how this has been implemented on the SGX, but I suspect it was
done through a legacy API called PVR2D. That API is not directly
supported on the SGX and therefore it is not a good choice for
accelerating simple 2D operations like BitBlts, etc. A better choice
would be to implement them using the Cortex-A8's NEON instruction set
extension or to use the system DMA.
Yes, I'm aware the SGX on the OMAP3 is missing a blitter. I still
assumed that using pvr2d (I.e. using the 3D core to do blits) was
faster than using the Arm core? Another nice thing pvr2d gives us is
the ability to sync blits with vsync to avoid tearing. Also, what were
you referring to when you say blits can be accelerated "using the
Cortex-A8's NEON instruction set"? Does neon contain more pre-fetch
instructions over ARM's existing PLD (Which I've read is often a nop)?
If I were to port Qt's PowerVR plugin to use neon (or even memcpy) for
blits, how do I handle memory coherency? Is this done in hardware?
I.e. If I read from memory which has recently been rendered into by
the SGX, will the SGX automatically flush it's cache to main memory?
Cheers,
Tom
Of course, I have logged in. But the error is that this page is not
present.
WSEGL.h is very hard to get.:(. I have no way to get it though we have
bought several OMAP3 boards. It seems TI is not willing to give this
file to us.
> I manage the development of the Graphics SDK and DDKs for TI's
> OMAP35x processors and I would like to clear up some confusion
> regarding supported APIs and the performance of the SGX core on these
> devices. First of all, there is no single SGX driver. What we
> provide are drivers for OpenGL ES 1.1, 2.0, OpenVG 1.1 and EGL. The
> performance for each of these is very goodThe EGL library shipped with the SDK looks at /etc/powervr.ini (eughhh
- it also uses CRLF line endings!) and dlopen's the specified WSEGL
plugin library, which is responsible for integrating with the window
system. The OMAP3 SDK (at least the one I've been working with) comes
with several WSEGL plugins: X11, flip, front & blit. The last three
are pseudo window systems, which only give you a single "window" - the
whole screen.What we have done in QWS (Qt Window System) is implement our own WSEGL
library which is using pvr2d to blit the window's back buffer to the
frame-buffer (scan-out buffer). As a result, Qt's powervr plugin needs
both pvr2d.h and wsegl.h to build. These files, as far as I know, are
only available as part of the DDK.
pvr2d.h has not been included in our regular Graphics SDK releases
because this is not a supported API. I will look at including pvr2d.h
and wsegl.h in our next release, but I recommend you avoid using pvr2d
at the present time.
> The performance of X11 is an entirely different matter. I'm not
> certain how this has been implemented on the SGX, but I suspect it was
> done through a legacy API called PVR2D. That API is not directly
> supported on the SGX and therefore it is not a good choice for
> accelerating simple 2D operations like BitBlts, etc. A better choice
> would be to implement them using the Cortex-A8's NEON instruction set
> extension or to use the system DMA.Yes, I'm aware the SGX on the OMAP3 is missing a blitter. I still
assumed that using pvr2d (I.e. using the 3D core to do blits) was
faster than using the Arm core? Another nice thing pvr2d gives us is
the ability to sync blits with vsync to avoid tearing. Also, what were
you referring to when you say blits can be accelerated "using the
Cortex-A8's NEON instruction set"? Does neon contain more pre-fetch
instructions over ARM's existing PLD (Which I've read is often a nop)?If I were to port Qt's PowerVR plugin to use neon (or even memcpy) for
blits, how do I handle memory coherency? Is this done in hardware?
I.e. If I read from memory which has recently been rendered into by
the SGX, will the SGX automatically flush it's cache to main memory?
You can actually get better performance for simple bitblt operations
by doing them on the ARM Cortex, rather than through pvr2d. That is
the main reason we don't support pvr2d on OMAP. NEON can help with
more complex blts because of its ability to process 4 pixels per clock
cycle. You must synchronize the transfers with the vertical sync to
avoid screen tearing problems. This is not done automatically by the
SGX.
Regards, Clay