Program Epiphany to act as a GPU

[mchampigny]

As jar mentioned, OpenGL is not a graphics driver. It's an industry standard API maintained by the Khronos Group. There are several software-only implementations available and the only requirement is that the rendering that appears on the frame buffer is compliant with the specification. The ARM cores (Cortex-A9) on the Zynq render to a dumb frame buffer on the Parallella and there is no hardware acceleration because there is no GPU on the Zynq (well, there may be some assist from the NEON SIMD instructions on the Cortex-A9, but that's a fine point). The cores on the Epiphany are not involved at all.

If you are truly interested in GPUs and graphics APIs (Vulkan, OpenGL, etc.) then a good project would be to develop a Gallium based driver making use of the Epiphany cores as best you can. As I mentioned in another post, a similar approach was taken with the Cell SPUs. Many of the math intensive graphics operations were offloaded to the SPUs leaving the PPU core to orchestrate. I believe the same general approach could work with Epiphany, though your results might vary. I suspect the much larger scratch memory on the SPUs, 128-bit registers and rich SIMD ISA, and higher bandwidth DMA engines would give the Cell SPU driver much improved performance over what you could obtain from Epiphany, but Cell is dead and you work with what you have.

You have your work cut out for you.

[CarstenT]

hi jar & mchampigny
I appreciate your input and I will follow your links.
I've never learned any formalities about programming, so doing opengl was a hard one to crack.
I feel that making 'graphics' on parallella, out of nothing, must be a challenge that's beyond me.
I'm pretty curious though, .. and that's always where it starts, right?

//edit//
jar, I saw a bit of your code
void render_scanline(..)
must be the heart of it all .. like when you've written GL_draw_elements(..) and think "gee, all that trouble to finally get there"
Like in opengl it might be about the draw-call .... all the rest is annoying details (and lots of them)

[jar]

[CarstenT]

Hi jar,
I've spent the past years in openGL, so I'm not in doubt about openGL basics.
My initial outset was visualizing an 1000*1000 carpet of heights into a view of a terrain.
Second, I wanted to be able to 'draw' my own data into it. This last produced a simple 'freehand-editor' that I'm currently rewriting. Unfortunately, I've fallen into the idea to produce a customizable GUI. It's not very demanding on memory and could be usable in a epiphany context. But it's a project that takes me stray-off from making a simple, usable 3d-modelling interface. This also makes epiphany-projects a lower priority. If, for nothing else, because I don't have a private net-connection .. I cannot just jump to it on a whim.
With my openGL experience you probably can understand that I find 'painting the epiphany-screen' agreeably easy for plain d2 drawing - if I get you right.
The image you linked to says that you have your own deep understanding of what, how & where. Generally I've got much less respect for geometry as such, than for interfacing with openGL where it's integrated.
OpenGL does not allow partially repainting ... do you have to redo the whole framebuffer for each draw on parallella, or can you do a local update of a sub-region?
Another thing, your code looks like manipulating single binaries (>>SHIFT) - I'll have to hesitate on jumping into new code semantics and structure, but I do already have a book on assembly-language if need be.

I got a time-out at my last post and didn't manage to copy your links. Being without a private connection has it's quirks, but certainly also it's blessings ;O)
cheers