Open Source ARM Userland

I took a quick look at github but I didn't see any "doc" subdirectory.  Is there any documentation of the interface, or is it all a bunch of undocumented source code with unhelpful symbolic constants and function names?  I hope the former, but a comment at the RasPi 'blog post suggests it could be the latter.

Yup, now you can lick the frosting but don't taste the cake ...

Sounds like it's just the layer between the opengl es, openvg and openmax and the binary blob that handles the calls.

It should be usefull when porting other oses to the Pi, but if you stick with linux you might as well use the

library functions themself I assume.

This kind of movements make me angry because they seem to be made to hide the fact that the Broadcom chip being so closed could be correctly use for education purposes. I remember Abishur attacking people saying there was no need for more openess because we could use OpenGL and wrong arguments to give the impresion there was nothing to be fixed...

Now they do and they say we have to say thank to Broadcom because nobody does that and we do not deserve it (Why would someone need to have source code anyway?).

I had a bad feeling when I started my iterations with the people at the Foundation(tm) because the charity view the were supposed to take was difficult to asume for me. The other day I read somewhere some Eben quotes talking about his MBA and "developing the brand" and large amount of devices out... It's like they take a bizarre position just to achieve their purposes but one side ata a time. We have now the "good" side of openess and community benefit but I'm fearing the next movement for the "Bussinnes partners" (element14/farnell/RS and Broadcom in the dark).

John Beetem wrote:

 

I took a quick look at github but I didn't see any "doc" subdirectory.  Is there any documentation of the interface, or is it all a bunch of undocumented source code with unhelpful symbolic constants and function names?  I hope the former, but a comment at the RasPi 'blog post suggests it could be the latter.

Eben Upton answered my question at Slashdot:

Eben Upton wrote:

 

To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.

Works for me.  I have plenty to do in the mean time.

What's the point of documenting the GPU interface?  Are applications supposed to use the GPU interface now instead of using GL_ES?  Looking at the code, most of the functions are simple shims, so there would be no gain from bypassing them.

https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c

free.quark wrote:

 

What's the point of documenting the GPU interface?  Are applications supposed to use the GPU interface now instead of using GL_ES?  Looking at the code, most of the functions are simple shims, so there would be no gain from bypassing them.

 

https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c

It means you don't have to be running Linux (whether it's GNU/Linux, Android/Linux, MeeGo/Linux, ...) in order to use the GPU.  You can write a bare metal application that boots off an SD Card and talks to the GPU with binary calls.

Running a mainframe operating system like GNU/Linux gives you lots of services, but it comes with lots of baggage.  There are times when you want an 18-wheel trunk but other times when you want a bicycle, and the extra wheels just get in the way.  An excellent example is a real-time application where the Linux scheduler could present problems.  Opening up the GPU interface gives you that flexibility.  JMO/YMMV

John Beetem wrote:

 

free.quark wrote:

 

What's the point of documenting the GPU interface?  Are applications supposed to use the GPU interface now instead of using GL_ES?  Looking at the code, most of the functions are simple shims, so there would be no gain from bypassing them.

 

https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c

It means you don't have to be running Linux (whether it's GNU/Linux, Android/Linux, MeeGo/Linux, ...) in order to use the GPU.  You can write a bare metal application that boots off an SD Card and talks to the GPU with binary calls.  ...

 

 

I still don't understand.  Does linking with this shim pull in Linux modules?

coder27 wrote:

 

John Beetem wrote:

 

free.quark wrote:

 

What's the point of documenting the GPU interface?  Are applications supposed to use the GPU interface now instead of using GL_ES?  Looking at the code, most of the functions are simple shims, so there would be no gain from bypassing them.

 

https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c

It means you don't have to be running Linux (whether it's GNU/Linux, Android/Linux, MeeGo/Linux, ...) in order to use the GPU.  You can write a bare metal application that boots off an SD Card and talks to the GPU with binary calls.  ...

 

 

 

I still don't understand.  Does linking with this shim pull in Linux modules?

Here's my understanding: free.quark is saying that the newly-opened userland code is basically just a bunch of shims that take user-level OpenGL calls and convert them into binary messages which are sent to the GPU.  Without the open source and future documentation, it's hard to know what the message format is so you have to use the GNU/Linux modules.

With the open source and future documentation, we should be able to find out how to pass these messages directly to the GPU without having to use GNU/Linux modules.  This permits non-Linux operating systems or bare metal programs to talk to the GPU.  They're still using the same OpenGL functions, but calling them with messages instead of function calls that prepare messages.  At least that's my understanding.

If you're writing an OpenGL application for GNU/Linux, you might as well continue to use the GNU library and Linux driver.  You might be able to save some function call overhead by talking to the message interface directly, but it's probably not worth the trouble.

There isn't really much of "message format".  The same parameters are passed in the same order,

and RPC_CALL4 means there were 4 parameters.

For example on line 488:

GL_API void GL_APIENTRY glClearColor (GLclampf red, GLclampf green, GLclampf blue, GLclampf alpha)

{  

    CLIENT_THREAD_STATE_T *thread = CLIENT_GET_THREAD_STATE();  

    if (IS_OPENGLES_11_OR_20(thread)) {     

         RPC_CALL4(glClearColor_impl,

                thread,

                GLCLEARCOLOR_ID,

                RPC_FLOAT(red),              

                RPC_FLOAT(green),               

                RPC_FLOAT(blue),               

                RPC_FLOAT(alpha));

        }

}