2D acceleration

Hello guys!

I was just thinking of the SGX acceleration module of OMAP3530 on my BeagleBoard C4... is it possible to get some 2D acceleration by the chip? Primarily chroma keying and simple surface blitting would be needed. According to some (QNX) forum topics on SGX, this chip is not capable of 2D acceleration, only 3D - to be honest, I can hardly believe this, but I'm pretty sure there are a few experts who can share the truth with me.

So, how about 2D acceleration on BB? :slight_smile:

Thanks, regards,

Tamas Selmeci wrote:

Hello guys!

I was just thinking of the SGX acceleration module of OMAP3530 on my
BeagleBoard C4... is it possible to get some 2D acceleration by the chip?
Primarily chroma keying and simple surface blitting would be needed.
According to some (QNX) forum topics on SGX, this chip is not capable of 2D
acceleration, only 3D - to be honest, I can hardly believe this, but I'm
pretty sure there are a few experts who can share the truth with me.

yet it is true. TI did not license the 2D part

people have tried to implement 2D accell with the 3D engine and found
it slower than using only the CPU...

Hello Vladimir!

yet it is true. TI did not license the 2D part

people have tried to implement 2D accell with the 3D engine and found
it slower than using only the CPU...

Ohh no... pretty bad news.

I thought of implementing some 2D by using the 3D engine... perhaps I'll give it a chance in my spare time.

By the way, according to my (QNX) test utils, I can't get no more than 40 fps when displaying full screen images (800x480, BGR888). It could be fast enough, but my application uses a few small UI elements needed to be flooded by the background, and it's very slow, especially when it comes to chroma keying. Even with a few small tricks, I was unable to exceed 10 fps.

In general, what are your experiences regarding 2D speed?

Regards,

Tamas Selmeci wrote:

Hello Vladimir!

yet it is true. TI did not license the 2D part

people have tried to implement 2D accell with the 3D engine and found
it slower than using only the CPU...

Ohh no... pretty bad news.

I thought of implementing some 2D by using the 3D engine... perhaps I'll
give it a chance in my spare time.

By the way, according to my (QNX) test utils, I can't get no more than 40
fps when displaying full screen images (800x480, BGR888). It could be fast
enough, but my application uses a few small UI elements needed to be
flooded by the background, and it's very slow, especially when it comes to
chroma keying. Even with a few small tricks, I was unable to exceed 10 fps.

In general, what are your experiences regarding 2D speed?

I am the wrong one to ask, most I care for is video decoding and that
uses the overlays and no 2D/3D :slight_smile:

Tamas,

I got 60fps at 1280x720 with an 8-bit palette. I demo'ed parallax
scrolling with 3 plans and a fews tens of sprites. No alpha, only a
single color key for transparency. All of that is pure CPU work and
consumes about a third of cpu budget (BB-c4 @ 720MHz).
This has been designed for games, but is certainly suitable for apps.
To speed up more, AFAIK the (documented) DMA engine is our friend. Not
yet tested though.

BR

Hello Laurent!

In general, what are your experiences regarding 2D speed?

I got 60fps at 1280x720 with an 8-bit palette. I demo'ed parallax
scrolling with 3 plans and a fews tens of sprites. No alpha, only a
single color key for transparency. All of that is pure CPU work and
consumes about a third of cpu budget (BB-c4 @ 720MHz).

Sounds very good.

This has been designed for games, but is certainly suitable for apps.
To speed up more, AFAIK the (documented) DMA engine is our friend. Not
yet tested though.

If I could reach such a performance I'd be very satisfied. 60 fps with transparency is a bit more than I currently need, but the FPS can never be high enough :slight_smile:

What do you think, by using the 2.6.3x kernel for BB C4 and the related graphics libs, can I expect something similar performance? Let's assume I don't want to write device drivers, just use the current free infrastructure for linux...

Regards,

Laurent GONZALEZ wrote:

I got 60fps at 1280x720 with an 8-bit palette. I demo'ed parallax
scrolling with 3 plans and a fews tens of sprites. No alpha, only a
single color key for transparency. All of that is pure CPU work and
consumes about a third of cpu budget (BB-c4 @ 720MHz).
This has been designed for games, but is certainly suitable for apps.
To speed up more, AFAIK the (documented) DMA engine is our friend. Not
yet tested though.

you will find that the DMA is also rather slow :slight_smile:

BUT - it can run in parallel to the CPU, so if you can pipeline
your work, it might still help.

Hello Laurent!

In general, what are your experiences regarding 2D speed?

I got 60fps at 1280x720 with an 8-bit palette. I demo'ed parallax
scrolling with 3 plans and a fews tens of sprites. No alpha, only a
single color key for transparency. All of that is pure CPU work and
consumes about a third of cpu budget (BB-c4 @ 720MHz).

Sounds very good.

This has been designed for games, but is certainly suitable for apps.
To speed up more, AFAIK the (documented) DMA engine is our friend. Not
yet tested though.

If I could reach such a performance I'd be very satisfied. 60 fps with
transparency is a bit more than I currently need, but the FPS can
never be high enough :slight_smile:

In any case don't try to go higher than what your display device is
capable. :slight_smile:

What do you think, by using the 2.6.3x kernel for BB C4 and the
related graphics libs, can I expect something similar performance?
Let's assume I don't want to write device drivers, just use the
current free infrastructure for linux...

About a pure software lib that blits tiles/sprites, you don't care the
version of the kernel. Just request a plain memory area being a video
frame buffer, and care about writing to that memory optimizing the use
of the memory system.

About using the DMA as a companion to increase perf (if ever possible,
see vladimir's answer), I don't know whether linux has a driver for it,
and even when there were one, I am not certain it allow to use the
keying mechanism.

Laurent GONZALEZ wrote:

What do you think, by using the 2.6.3x kernel for BB C4 and the
related graphics libs, can I expect something similar performance?
Let's assume I don't want to write device drivers, just use the
current free infrastructure for linux...

About a pure software lib that blits tiles/sprites, you don't care the
version of the kernel. Just request a plain memory area being a video
frame buffer, and care about writing to that memory optimizing the use
of the memory system.

Is it a simple mmap operation or a dedicated library is advices to be used? If the latter, what's the name of that lib? Having a pure framebuffer is preferred by me. Was this the thing that made it possible to reach that 60 fps? Keying is supported by library or done by yourself?

I consider porting my QNX application to linux to get better gfx performance, that's why I need to know as much as possible.

About using the DMA as a companion to increase perf (if ever possible,
see vladimir's answer), I don't know whether linux has a driver for it,
and even when there were one, I am not certain it allow to use the
keying mechanism.

Okay, it is not that important if I can get adequate gfx performance with the pure library.

Regards,

I did everything by myself, mmap'ed the frame buffer area and wrote
adequate user routines to do a fast blit, not using any external lib.
The way I did it only has two dependencies regarding the OS: mmap of the
frame buffer and the way to get sync with vertical refresh. In others
words, the performance should be roughly the same whatever the OS.

Did you investigate the use of specialized graphic libraries like Qt,
e17 or SDL ? At 800x480, I assume you can reach 60 fps without big troubles.

Laurent GONZALEZ wrote:

I did everything by myself, mmap'ed the frame buffer area and wrote
adequate user routines to do a fast blit, not using any external lib.
The way I did it only has two dependencies regarding the OS: mmap of the
frame buffer and the way to get sync with vertical refresh. In others
words, the performance should be roughly the same whatever the OS.

Did you investigate the use of specialized graphic libraries like Qt,
e17 or SDL ? At 800x480, I assume you can reach 60 fps without big troubles.

I haven't investigated any of them yet. QNX has a basic graphics lib called libgf (Graphics Framework), and I fear that Qt, SDL etc. would also rely on that - so no performance improvement could be achieved.

By the way, I'll check them by all means.

Thanks,

Qt has a hardware accelerated display graphics system in OpenGL with several graphic drivers for the SGX (including their own PowerVR driver plugin), I would not consider doing a 2D UI without it (see QML)

Qt don’t relies on libgf, it has their own graphics implementation and uses OpenGL/DirectFB/Raster/X/Wayland as the backend

Lioric

Qt has a hardware accelerated display graphics system in OpenGL with several graphic drivers for the SGX (including their own PowerVR driver plugin), I would not consider doing a 2D UI without it (see QML)

And *only* the opengl bits (QGL*) are hardware accelerated, everything else will use software fallbacks.

Qt has a hardware accelerated display graphics system in OpenGL with several graphic drivers for the SGX (including their own PowerVR driver plugin), I would not consider doing a 2D UI without it (see QML)

And only the opengl bits (QGL*) are hardware accelerated, everything else will use software fallbacks.

Yes, I was referring to the multiple Qt SGX plugin graphic drivers that uses the OpenGL ES 2 backend in the beagleboard

Lioric

I'm pretty sure that the SDMA allows color-keying. Not sure if it can do
two dimensional transfers though.

There is also a driver for the EDMA in the linuxutils package. The EDMA
allows three dimensional transfers which is very useful for ordinary
blits, rectangle fills ect.