Skip to main content


Topic: Demonstration of Threaded OpenGL (Read 2910 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Demonstration of Threaded OpenGL
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:

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

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Demonstration of Threaded OpenGL
Reply #1
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Demonstration of Threaded OpenGL
Reply #2
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.
  • Last Edit: March 31, 2014, 07:34:05 pm by Flying Jester

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Demonstration of Threaded OpenGL
Reply #3
Reminds me of recent developments and talks from the major GPU driver developers on OpenGL and its efficiency. Has anyone seen this?

Re: Demonstration of Threaded OpenGL
Reply #4
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.
  • Last Edit: April 01, 2014, 09:37:14 pm by Flying Jester

Re: Demonstration of Threaded OpenGL
Reply #5
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.   ;)