Mali OpenGL ES 2.0 SDK

[ab1jx]

Docs are linked from
https://developer.arm.com/products/graph...li-450-gpu
see DUI0607C_mali_opengl_es_20_sdk_for_linux_on_arm_ug.pdf

This is a weird URL but it was hard to find:
http://openlinux.amlogic.com:8000/downlo...x86.tar.gz  I think arm/mali pulled it

I managed to get all the examples to build on a Raspberry Pi, but it doesn't have a Mali so they don't run.  There's one called frame_buffer_object that's a spinning cube and on each of its faces is another spinning cube, supposedly anyway.

If you've got all the prerequisites installed, unpack the tar.gz.  In the directory that creates make a build_arm directory and cd into it.
do:
export TOOLCHAIN_ROOT=/usr/bin/
then
cmake -G "Unix Makefiles" -DTARGET=arm ..

If it builds OK look in the samples directory that gets created.  There are samples of OpenGL ES 2.0, 3.0, 3.2.

[dkryder]

looking through 6 year old .pdf you linked i asked myself "self, at what point is it time to just move on?". self answered with, "click red "X" in upper right hand corner". done. ymmv.

[ab1jx]

looking through 6 year old .pdf you linked i asked myself "self, at what point is it time to just move on?". self answered with, "click red "X" in upper right hand corner". done. ymmv.

Yes, it's old.  But in a way it's the owner's manual for the OpenGL ES that's built into the Mali 450.  I've been trying to get started studying OpenGL ES for a month or three, with a lot of false starts.  You don't want to just study OpenGL, in fact you may not even want to have it installed, because that's likely to lead you down the path of software rendering.  If you want full acceleration you need to study what's built into the chip.  That can't change.

I've been around Linux for 20 years now.  I remember OpenGL as slow and pretty.  That's because it was software rendered.  I don't know yet if there's any advantage beyond accelerated X to even having a Mali for using software like the OpenGL you'd install from the debs.  Maybe that passes primitive stuff to the native EGL, I don't know.  I've read you have to be careful what your programs are linking to.  Generic OpenGL these days will run on about anything, I want to drive the Mali, if for no other reason than to take load off the CPU and shift it to the GPU.

What I want to find time to work on is SDR, software defined radio.  "shaders" in OpenGL are little programs that run in the GPU.  I think I can pass an array of realtime radio data to a shader and have it calculate and plot on the screen, which frees the CPU do things like demodulating the audio.  There's a very significant fraction of a Rock64's processing power sitting there in the GPU, I'm trying to be sure I'm using it.

[MichaelRock]

@ab1jx: I advise you to take a look at Nehe's OpenGL tutorials, they're great, with a gentle progress curve (AFAIR, I've play with them quite 14 years ago).

And for the shaders, if you are not too much in a rush, the best may be to learn shaders using DX9 and XNA/MonoGame as explained by RB whitaker in his wiki. You may have ot learn C# in the process . I've learn this way and it could be easier and better in the long run, as DX9 have only 2 programmable steps in the rendering pipeline: vertex and pixel shaders (allowing moving vertices and altering colours using the GPU power), DX11 and up add more shaders like a geometry shader which gives more opportunity to play but needs also more to learn first.

The important point about shaders to remember is they lie inside the GPU, which mean there is no feedback to the CPU(*) (shaders are in the rendering step, almost the last in frame generations for games), so they can't be use as a game feature like knowing if an object is under a shadow or not. They still hold a very great power as bloom filtering, all/many sampling (FXAA, Anisotropic, etc they are so much these days), light & shadows, motion blur, reflections, and so on.

(*) not 100% true as texture sampling allow to generate results from calculations and get the result from the generated colour reading the frame buffer data.

[ab1jx]

I don't even know enough yet to know if OpenGL ES 2 and 3 can even use shaders.  The Broadcom VideoCore 4 in a Raspberry Pi does ogles 2 and the Mali 450 does ogles 3 (I think).  I don't need feedback from the GPU which is what seems perfect.  I'd take data from the FFT and feed it to the shader for scaling and plotting.  Visual output is the end product of that branch.  Meanwhile I'd feed another copy of the data through an audio demodulation process then to the sound card.  It might be 4000 data points 10 times a second, something like that.

In the Raspberry Pi documentation and examples there are people that have used the GPU for things like FFT and SHA256 like for mining Bitcoin, but from assembly, not OpenGL ES.  I think the GPU is about 10 times as fast as a single core CPU.  The Rock apparently has an OpenCL implementation, that could be useful for mining.  Except the competition runs 1000 watt PCs with multiple Nvidia and ATI cards to mine on.  What's cost effective is a real issue, older slower rigs use more electricity than the money they make.  People use solar electricity to tip the balance.