OpenGL ES 2.0 for Parallella with RPi

[shodruk]

Because I want to use 3D graphics with Parallella, I wrote a small framework that enables Parallella to use OpenGL ES 2.0.

source code
https://github.com/shodruky-rhyammer/gl-streaming

demo video
http://youtu.be/6S-Epb6m6mI

It streams OpenGL commands from Parallella to Raspberry Pi over network, and render 3D graphics on RPi.
Although Parallella does not have a GPU, it can use full OpenGL ES 2.0 with this framework.

gl-streaming summary

gl-streaming_small.png (124.23 KiB) Viewed 40245 times

Because RPi only costs $35, it could be considered as a cheap graphics add-on board for Parallella
I think it also could be a breakout board, so I will try it next time.

Because I don't have Parallella yet, this demo was captured with x86 PC(client) and Raspberry Pi(rendering server).
Will someone please try this program on early Parallella board?

[Gravis]

ok with all the talk about GPUs and whatnot, i really want to know, why not use the epiphany for GPU operations?!

seriously, it can do the math. if you want assistance manipulating the framebuffer, you could employ some fpga logic. completely ignoring the epiphany's floating point processing capabilities is practically criminal.

[shodruk]

ok with all the talk about GPUs and whatnot, i really want to know, why not use the epiphany for GPU operations?!

seriously, it can do the math. if you want assistance manipulating the framebuffer, you could employ some fpga logic. completely ignoring the epiphany's floating point processing capabilities is practically criminal.

I think that is important too, to utilize Epiphany's floating point processing capabilities.
Simply, I made this because I just wanted to do.
Please imagine that Epiphany calculates complex physics or artificial intelligence or something worth to do, and RPi visualize it.
Wouldn't it be nice?

Aside from it, writing 3D graphics renderer is fun, so I think it is worth to try.

[LamsonNguyen]

Nice job, enable OpenGL compatibility and the desktop gamers will come.

[shodruk]

Nice job, enable OpenGL compatibility and the desktop gamers will come.

Thanks!
I connected playstation3 controller, and tried some demo, I could not feel latency at all.
This is usable for gaming, really!

[over9000]

This is very nice
I have a couple of thoughts. The first is about using this to drive a display wall, with one Pi per screen. I wonder how hard it would be to run multiple OpenGL client instances, each with a different viewport. I'm sure bandwidth could be an issue, though I'd say that could be overcome with the appropriate router hardware (Parallella's 1Gb net should be able to feed 4 Pis each on their own 100Mb network segment, though the routers will also introduce latencies).
The second thought is about complex scenes (like in 3d games or apps with high poly count). I don't see any texture caching in the code, but it seems like it should be doable within the OpenGL pipeline.
It's nice to see that I can actually compile the client on my regular desktop machine, too, since I don't have a Parallella board yet. When I have access to my Pi later, I'll try compiling that side and see what happens.
One last thing... maybe you should let the RPi guys know about this. I'm sure they'd love to see this in operation.

[shodruk]

This is very nice
I have a couple of thoughts. The first is about using this to drive a display wall, with one Pi per screen. I wonder how hard it would be to run multiple OpenGL client instances, each with a different viewport. I'm sure bandwidth could be an issue, though I'd say that could be overcome with the appropriate router hardware (Parallella's 1Gb net should be able to feed 4 Pis each on their own 100Mb network segment, though the routers will also introduce latencies).

Yes ! I thought that too.
I think it is easy to implement multi-gl_server system. (however single server and multi-client is hard.)
Because each server only knows their own GPU and OpenGL device context. There is no need to modify gl_server.
On gl_client, there is need to implement a device context switching method, but it is easy, too.
Just running multiple client and server(client's server), and switching IP addresses to send.
But, user programs must manage multiple OpenGL contexts and switch it manually, of course.

This is exciting to do, and very cheap multi-monitor system.
I can buy four RPis easily, but, monitor.... I wish I could be rich.

The second thought is about complex scenes (like in 3d games or apps with high poly count). I don't see any texture caching in the code, but it seems like it should be doable within the OpenGL pipeline.
It's nice to see that I can actually compile the client on my regular desktop machine, too, since I don't have a Parallella board yet. When I have access to my Pi later, I'll try compiling that side and see what happens.

I have not implement texture mapping yet, but it's easy, and there is no problem. All texture data and complex vertex data are transferred to GPU memory (or server's main memory), and is used repeatedly, so client and network are not affected.
... except long initializing stage

One last thing... maybe you should let the RPi guys know about this. I'm sure they'd love to see this in operation.

I just have advertised this in RPi and OpenGL forum.

[LamsonNguyen]

This is exciting to do, and very cheap multi-monitor system.
I can buy four RPis easily, but, monitor.... I wish I could be rich.

http://www.kickstarter.com/projects/sfen/able-hd-portable-hd-monitor-for-laptop-and-smartph
Problem solved!

[shodruk]

http://www.kickstarter.com/projects/sfen/able-hd-portable-hd-monitor-for-laptop-and-smartph
Problem solved!

Oh, that's very reasonable! I want that

[shodruk]

Hi, I just uploaded a texture mapping demo video of gl-streaming.
(Caution: weird video.... )

http://youtu.be/y0eRwrwetcA