It seems like the knee-jerk reaction every programmer has when I tell them that TurboSphere has a threaded OpenGL rendering backend is 'You can't thread OpenGL!'

Well you can. And more than just putting ALL OpenGL calls in a different thread, you can perform data manipulation in one thread and rendering commands in another. You can even upload data to the GPU completely asynchronously.

Here is the proof: https://github.com/FlyingJester/GL_On_A_Stick.

Don't let anyone tell you that OpenGL can't be threaded. You just need to be careful and confident about it

I believed in you all the way when you said OpenGL can be threaded! (Though I might have not said it.)

Cool project. This definitely the kind of small-test thing I can get behind. How does it compile? Is it fairly straight-forward in Windows/Linux/OSX? If so, I like to think it's a standard to a how-to install method in your readme.

I figured that folks here trusted me. But it's nice to have a concrete example to point to 

For compiling, just have Python and Scons, call 'scons' on the root directory.

It really should work identically between Windows, OS X, and Linux, and using just about any C or C++ compiler. I wrote it for MSVC's C11 (which is more like C99+), I designed it to load OpenGL the same way TurboSphere does (querying function availability and loading at runtime), and included all the stuff for SDL2.

The one issue I can imagine is that GLoas relies on `#pragma once' working. But that works in every C and C++ compiler I've used, so I'm not too worried.

Reminds me of recent developments and talks from the major GPU driver developers on OpenGL and its efficiency. Has anyone seen this?

I hadn't seen that before.

That looks like it was addressing a similar problem to one that had been solved by AMD_pinned_memory and cube maps. The actual solutions are different, though.

I'm not sure I've ever seen a case where it would be particularly applicable. It requires you wanting to move huge amounts of vertex data at regular intervals--but far more than a frame of data, and far less often than every frame. It's probably just that I've never needed such a solution.

The sparse texture bit looks like you would need to know about texture usage, or else it would be as complicated as cube maps.

That talk does show part of why threading GL calls is good, though. Often times the client-side/in-thread GL calls are not nearly as thin as they look (more true on cheaper hardware, where the software part of the driver takes over where the hardware is lacking), and there are many, many calls that cause synchronization. The idea is that we need to do all kinds of other calculations, so we can make these GL driver calls, both server and client side, asynchronous to the program. We eat the synchronization delays, but whenever possible we use that time for other processing.

In the case of TurboSphere, it would be possible (more conceptually than not, but still quite possible) that the delay for a drawing JS function could be shrunk quite a bit. Just data validation, store the parameters, and then return.

There we go, it's now been tested and works fine so far on Windows and Linux.

I actually wonder if this technique wouldn't be well applied to a Sphere video driver. The ancient spidermonkey and slow immediate-mode GL may keep pace with each other well.