Use of GPU on OMAP, drivers and their status


alastor

Still Fresh
Joined
Oct 23, 2010
Messages
42
Age
31
First of all - it is good to see that now people are slowly getting their units :D ( I am not getting a unit, unfortunately, due to personal reasons. However it surely feels great that now more devs will get their devices and start coding, so people like me, who have ordered Pand...abord, will benefit. Of course I will do my part too. )


So now, as I will very soon get my first ARM/OMAP device, one thing still bothers me. The usage of this "cool" POWERVR GPU core on SOC that is. After hours of research it seems to me that finding facts about SGX is a real pain in ***. I want to find things that make SGX different from ... bare framebuffer device.


To put it straight - which applications actually use something more than primitive framebuffer ? ( If you have no experience with "pure" framebuffer video output, lets just say - it really sucks. No 2D/3D acceleration, no hardware scaling, no YUV to RGB conversation, etc. And I have this experience, running linux on PS3. )


Please answer those questions and I think it would be useful for users to know about current SGX status.


Are most ported games use only frame buffer output ?


How come it is so ******* hard to find applications that actually use OpenGL ES 1/2, when those Android/Mac/Maemo/Linux powered devices are so popular ? :blink:


If porting every single OGL application means rewriting it to GLES, why there is still no OGL driver available when hardware would obviously handle it ?


Can we use Gallium3D driver ( From Mesa ) for OpenGL staff ? ( There is even Gallium for Cell, although I must say it was the most stupid idea I have heard about in my life as a linux user. The project failed. It is of no use. )


Is Xorg hardware accelerated when using open-source driver or closed-source binary from IMGTEC ? ( I wouldn't believe if you are using software rendering in X ... I hope you are not. What is the point of promised 2D acceleration then ? )


Is XV ( XVideo, video output plugin ) hardware accelerated ? ( Scaling, colour conversation ? ) Are you using it when playing videos with Mplayer ? Or is it DirectFB, fbdev, similar driver ? ( Most important question for me. )


What about this:


"Video Performance


The parallel, multi-threaded PowerVR SGX architecture combines highly scalable processing power with the flexibility of a programmable device, which enables SGX to perform not only 2D and 3D acceleration but also acceleration of an extensive range of video standards. PowerVR SGX family video/image decode and encode processing support includes H.264, MPEG-4/2, VC-1 (WMV9), JPEG and others."


? I don't get it - are there decoders in SGX ??? What the point of having DSP/IVA then ? :blink:


Thank you for reading.
 
One thing you should know is that OMAP3530 has a pretty decent display subsystem. While accessing the framebuffer directly you can still get scaling (with a polyphase FIR filter), YUV to RGB, and multiple layers. Pandora's kernel does expose this in its framebuffer device, and lots of things have been using it because it's by far the most efficient way to perform these operations.


The other thing you have to understand is that for games that do want a purely software generated framebuffer, having the SGX perform the operations you've suggested is a performance hit because updating big textures constantly isn't the expected usage model. There are some extensions to make it pretty fast, but there's still a cost involved (and it uses more memory bandwidth no matter how it's performed).


It's probably so hard to find ES applications because despite their popularity most mobile software is closed source. There's no OGL driver because this sort of software costs a lot of money to develop and IMG doesn't want to help vendors support it for free. OGL ES 2 is a more suitable target for resource constrained devices like these anyway. Especially on something like Android, they wouldn't want to offer OGL 2 support that only worked on IMG GPUs. These SoCs really weren't meant for broad open devices that would be driven more by porting than new content like Pandora was. You can see how supporting existing OGL applications isn't exactly a priority unless the GPU is paired with an x86 CPU that runs Windows (where it'd make more sense to support D3D anyway).


Porting from OpenGL 1.x to OpenGL ES 1.1+ isn't really a huge ordeal. For OpenGL 2 support, there's at least one wrapper that aids in providing the fixed function capabilities in ES 2 shaders.
 
Thanks Exophase - nice explanation.

One thing you should know is that OMAP3530 has a pretty decent display subsystem. While accessing the framebuffer directly you can still get scaling (with a polyphase FIR filter), YUV to RGB, and multiple layers. Pandora's kernel does expose this in its framebuffer device, and lots of things have been using it because it's by far the most efficient way to perform these operations.
You mean DSS, don't you ?


EDIT: I have just seen it myself. This page explains its features:


http://www.mjmwired.net/kernel/Documentation/arm/OMAP/DSS


Awesome, I don't need to worry about scaling and color conversation then.

Porting from OpenGL 1.x to OpenGL ES 1.1+ isn't really a huge ordeal. For OpenGL 2 support, there's at least one wrapper that aids in providing the fixed function capabilities in ES 2 shaders.
I think there are at least two wrappers. Anyway I will most likely start learning about GL and GLES, so it would be possible for me to get some nice game to work ... But firstly C.
 
Back
Top