Skip to main content
↑
↓
Spherical forums
Community for the
Sphere game engine
New?
Contact Us
to register an account!
1 Hour
1 Day
1 Week
1 Month
Forever
Community
Help
Search
Recent Posts
Log in
Contact Us
News
Spherical
Facebook
-
Twitter
-
Discord chat
New?
Contact us
to register an account!
Creations
Programming
Demonstration of Threaded OpenGL
1
Print
Topic: Demonstration of Threaded OpenGL
(Read 4498 times)
previous topic
-
next topic
0 Members and 1 Guest are viewing this topic.
Flying Jester
Legendary Poster
Posts: 1,161
Logged
TurboSphere Developer
Demonstration of Threaded OpenGL
March 31, 2014, 04:07:46 pm
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
Learn some history?
The Flying Jester's Blog of Sorts
Radnen
Big Chungus
Posts: 1,440
Sphere Studio Developer
Logged
Senior Staff
Wise Warrior
Re: Demonstration of Threaded OpenGL
Reply #1
–
March 31, 2014, 05:44:50 pm
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
Flying Jester
Legendary Poster
Posts: 1,161
Logged
TurboSphere Developer
Re: Demonstration of Threaded OpenGL
Reply #2
–
March 31, 2014, 07:28:16 pm
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
Learn some history?
The Flying Jester's Blog of Sorts
DaVince
Legendary Poster
Posts: 1,001
Logged
Administrator
Used Sphere for, like, half my life
Re: Demonstration of Threaded OpenGL
Reply #3
–
April 01, 2014, 10:21:30 am
Reminds me of recent developments and talks from the major GPU driver developers on OpenGL and its efficiency. Has anyone seen
this
?
Spherical Downloads Repo
||
My (really old) Sphere stuff
Flying Jester
Legendary Poster
Posts: 1,161
Logged
TurboSphere Developer
Re: Demonstration of Threaded OpenGL
Reply #4
–
April 01, 2014, 09:13:40 pm
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
Learn some history?
The Flying Jester's Blog of Sorts
Flying Jester
Legendary Poster
Posts: 1,161
Logged
TurboSphere Developer
Re: Demonstration of Threaded OpenGL
Reply #5
–
April 22, 2014, 12:46:57 am
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.
Learn some history?
The Flying Jester's Blog of Sorts
1
Print
Creations
Programming
Demonstration of Threaded OpenGL