Multithreading

OpenGL, as far as I know, doesn't natively contain any type of multithreading system. You should either A) use OS-specific API functions (for example, CreateThread() in Win32) or B) use another third party library. I highly recommend boost::threads, for good cross-platform functionality.

SDL also supports cross platform threading:
http://www.libsdl.org/index.php

Cheers,
- llvllatrix

Note also, that OpenGL functions are not thread safe, and nor are most windowing systems, so all windowing system and opengl calls will either have to be synchronised (using mutexes, etc.), or only called from a single thread.

Worse than the lack of any native threading safety, OpenGL contexts (HGLRC on windows) are bound to a specific thread when set as current. So in order to move OGL calls from one thread to another, you need to wglMakeCurrent( hDC, NULL ); in the old thread and wglMakeCurrent( hDC, hRC ); in the new one.

The rule of thumb with OpenGL and threads is:
Just don't freaking do it.

Localize all your rendering calls to a single thread, and use other threads for other things. All of OpenGL's calls are already buffered and run asynchronously anyway.

What are you trying to do, if you dont mind my asking?

Well I'm trying to work out a way to support HT(Hyper Threading) and/or SMP(Symmetric Multi Processing).

I saw the way it was implemented in Q3 but it was a bit more complicated. So I was searching for some tutorials and could not find any.

Except this but its quite brief www.ati.com/developer/ gdc/GDC2005_OpenGL_Performance.pdf

Allthough computer graphics is the champion of paralellism, it is allso it's strongest opponent.
I love to see a paralell capable graphics API/graphics accelerator but i just don't see that happening in the near future, perhaps in 3-5 years, but not before that.
I know how it could be done, i know the benefits of doing so, but they more or less laughed at me for sugesting anything like that on the openGL forums.

So before they decide that it's time for a change, well do as Promit suggest, Just don't freaking do it.

Pre processing on the other hand should work like a charm to have multithreaded (if you do it right that is).

Quote:

Original post by lc_overlord I know how it could be done, i know the benefits of doing so, but they more or less laughed at me for sugesting anything like that on the openGL forums.

Sorry, I don't poke on other gamedev forums. Could you please share with me/us your insights?

By the way, hyper threading is marketing hype. Don't get me wrong: having multiple logical threads is a good idea. It's the fact it doesn't need a special name or functionality.

To support HT, your program just needs to have support for threading. Then, when the OS supports and detects the threads, will mark them as affine threads. By using thread affinities, data caches can be shared much more efficiently.
I heard there are some ways to declare this explicitly but I'm not catched up with this.
A thread-friendly architecture also helps in making HT more efficient than real multi-CPU threading (proportionally), but nothing like having two real CPU cores on die.

Quote:

Original post by Krohm Sorry, I don't poke on other gamedev forums. Could you please share with me/us your insights?

No i made that post about a year ago on the opengGL.org forums.
basicly what i want it to be is a way to have two or more separate rendering pipelines, this way you could render shadows or whatever on one while doing the textures on the other at the same time.
The openGL commands would be fairly simple, perhaps something like this.

glGet(GL_MAX THREADS); <-returns the number of avalible threads
glActiveMultithread(GL_THREAD_1); <- for the default thread
glActiveMultithread(GL_THREAD_2); <- for the next thread
glActiveMultithread(GL_THREAD_1|GL_THREAD_2); <- for both threads

the threads would then render to separate FBO's and then you combine those before putting it in the backbuffer, it's pretty simple really and it give realtime 3d rendering a chance to take advantage of multithreaded dual core CPUs the but on the downside is the fact that graphics cards have to be redesigned a tiny bit to alow for this.

Quote:

Original post by Krohm To support HT, your program just needs to have support for threading.

Actuarly you don't have to do anything, it helps programs run smoother, that's all, not faster.
The effect is pretty aparent in some games where the gameplay is less jerky than before , but at the same framerate.
it's only when you actuarly have two physical cores when you "need" to add threading.

Quote:

Original post by lc_overlord Allthough computer graphics is the champion of paralellism, it is allso it's strongest opponent. I love to see a paralell capable graphics API/graphics accelerator but i just don't see that happening in the near future, perhaps in 3-5 years, but not before that. I know how it could be done, i know the benefits of doing so, but they more or less laughed at me for sugesting anything like that on the openGL forums. So before they decide that it's time for a change, well do as Promit suggest, Just don't freaking do it. Pre processing on the other hand should work like a charm to have multithreaded (if you do it right that is).

look into ray-tracing for a graphics technique that absolutely loves paralellism - performance scales linearly with the amount of processors, meaning that 2 CPUs = twice the performance (theoretically). This is because you can split the window into 2 (or however many processors you have) and process each segment on a different CPU.

Back on topic...

Quote:

Original post by MENTAL look into ray-tracing for a graphics technique that absolutely loves paralellism - performance scales linearly with the amount of processors, meaning that 2 CPUs = twice the performance (theoretically). This is because you can split the window into 2 (or however many processors you have) and process each segment on a different CPU.

True, and so does most other 3d graphics systems.
But, it is not the actual rendering that causes the problem, it is telling the graphics card what to render and in what order that is so horribly linear.

Quote:

Original post by lc_overlord Actuarly you don't have to do anything, it helps programs run smoother, that's all, not faster.

This comes rather new to me, I don't understand. How can it kick in with a single execution path?
As for the actual speedup, I read it from benchmarks floating around the internet 10-30% speedup for free. I have to understand they were telling bu11$|-|!7?

By the way, your threading ideas reminded me a proposal 3dLabs made when GL2 was rolling. But no one liked them and it was dropped (I still believe Permedia10 has support for them but I cannot be sure).
If my memory does not faults me, I believe they were proposing something like a per process multi-context (or maybe it was 'GL thread objects' as texture objects?).

On the topic, I read next java platform will have full SWING rendering using GL. To improve performance, they completely redesigned it to go in a single thread (don't ask me how they do it, see the java home page).
After reading this, I began thinking maybe rendering shall not be multithreaded at all. I obviously have to investigate this in more detail.

I think the best way to use multiple threads in an OpenGL app more likely is to do the rendering in one and something else in another, such as AI.

Quote:

Original post by Krohm Quote: Original post by lc_overlord Actuarly you don't have to do anything, it helps programs run smoother, that's all, not faster. This comes rather new to me, I don't understand. How can it kick in with a single execution path? As for the actual speedup, I read it from benchmarks floating around the internet 10-30% speedup for free. I have to understand they were telling bu11$|-|!7?

Simple, every app runs one or more threads on your system.
Now windows has a pretty bad multitasking witch means that one of the other less important threads could get to much processor time in one go, this can result in choppy rendering and so on.
With HT in place the system places your heavy and time critical thread on one logic processor and the rest on the other, at witch point the HT-processor interleaves the instrucions before processing it, resulting in much more smother operation and in some cases you even get better preformance.
Allso even though windows can report your app to be running at 50%, it doesn't, this is because it thinks it's running the program on only one processor of two possible, witch it isn't.

Quote:

Original post by Krohm By the way, your threading ideas reminded me a proposal 3dLabs made when GL2 was rolling. But no one liked them and it was dropped (I still believe Permedia10 has support for them but I cannot be sure). If my memory does not faults me, I believe they were proposing something like a per process multi-context (or maybe it was 'GL thread objects' as texture objects?).

Doesn't suprise me at all, multi threading is a good thing for computer graphics, but it does take a lot of redesign (both hardware and software) to get it running ok.
And as i understand it the original idea was to basicaly rewrite openGL, but that would have taken to much time to they cut away a lot of stuff so they could release it earlier.

Quote:

I don't remember the details about the hardware, but one of the machines capable of doing the rendering does indeed have a large number of rendering pipelines (24 I think) and processors.

Well, there's the problem of hardware diffusion. We're obviously speaking about two very different ranges.
Take for example 3Dlabs cards: they are very fast at pbuffers because what they really do is to have "GPU thread support". Something like the 386, in which multithreading were introduced.
I believe most professional video cards are actually very thread-optimized but unluckly, this does not apply to mainstream cards.

Supporting a multithreaded GL is obviously possible. The rendering context is just a shared resource which has to be locked and mantained with care. What I'm not sure of is its usefulness.
Having two CPUs will obviusly make GL commands much faster but will it cut it? There will be extra application management and extra driver work to take in careful consideration. Engineering-wise, it takes some effort and we need to be sure of the results, we're not interesting in getting only extra 10% right?

Quote:

Original post by kburkhart84 I think the best way to use multiple threads in an OpenGL app more likely is to do the rendering in one and something else in another, such as AI.

This is what it seems to be spreading around but there's a producer/consumer relationship between the engine and the GL which consumes the data. What Sun is doing with SWING says it all: do the computation on as much processors as possible but keep GL in a single thread.
I agree with you this seems to be The Right Way.

Quote:

Original post by lc_overlord Now windows has a pretty bad multitasking witch means that one of the other less important threads could get to much processor time in one go, this can result in choppy rendering and so on.

Are we speaking about thread switching or process switching? In the same process, there must be multiple threads for HT to work elsewhere, how can the two logical processors work? They obviously cannot do this in a single execution path.

Quote:

Original post by lc_overlord ...in some cases you even get better preformance.

That's exactly the point. This happens because HT is in fact a "fast thread switch". When the other thread kicks in, it'll find data caches already warmed up and some work may be avoided (but I'm not sure what work is actually skipped).

Quote:

Original post by Krohm Are we speaking about thread switching or process switching?

In this case it's more or less the same thing as it doesn't matter how many threads the processes have, as long as you have more than one on the whole system.

Quote:

Original post by Krohm In the same process, there must be multiple threads for HT to work elsewhere, how can the two logical processors work?

No, but if you only have one thread, it will only run on one of them, however there is probobly other procsses runing on the other logical processor.
But since it's a logical processor this doesn't matter.
A logical processor does not have 50% of the total computing power at all time, it uses what it needs.
Now if you have a dual core processor it is better to split it up in multiple threads.

Quote:

Original post by Krohm They obviously cannot do this in a single execution path.

Infact, there is only a single execution path at all time no matter how many threads or processes you have, unless you have a HT or a dual processor system that is, because then you have two or four or whatever the amount of logical processors you have.

Sorry, I don't understand.

Quote:

Original post by lc_overlord No, but if you only have one thread, it will only run on one of them, however there is probobly other procsses runing on the other logical processor. But since it's a logical processor this doesn't matter. A logical processor does not have 50% of the total computing power at all time, it uses what it needs. Now if you have a dual core processor it is better to split it up in multiple threads.

Well, I believe logical processors are scheduled according to standard management, with more attention to thread affinity.
This question originally investigated how the two logical processors can increase the performance... I believe we're actually agreed on the fact there is need for multiple threads but I'm not sure what you're meaning.

Quote:

Original post by lc_overlord Infact, there is only a single execution path at all time no matter how many threads or processes you have, unless you have a HT or a dual processor system that is, because then you have two or four or whatever the amount of logical processors you have.

I believe we're speaking about two different things.
I call execution path a sequence of operations. On a standard processor, there will be only one active (or 'current') execution path. This is to abstract the difference between 'thread' and 'process'.
You're possibly speaking of what i call 'active execution path'?

Quote:

Original post by Krohm Well, I believe logical processors are scheduled according to standard management, with more attention to thread affinity. This question originally investigated how the two logical processors can increase the performance... I believe we're actually agreed on the fact there is need for multiple threads but I'm not sure what you're meaning.

Yea you only need two threads, but not in the same process though.
It could help, but im not seing why it would work that much better with multithreaded applications.
The bottom line is that threads and apps run smoother in HT, it allso keeps them running more or less constantly witch means that the thread and it's work data is still being kept in the L2 and L1 cache, meaning it doesn't have to constantly reload this data.
So aparantly making things run smoother helps the speed a little by making it run a little bit more effectively.

Quote:

Original post by Krohm I believe we're speaking about two different things. I call execution path a sequence of operations. On a standard processor, there will be only one active (or 'current') execution path. This is to abstract the difference between 'thread' and 'process'. You're possibly speaking of what i call 'active execution path'?

Perhaps, but the active execution path thingy is only something windows messes with, the processor doesn't se this, it just recives streams of data and processes them.
And even if windows does as i think your saying it does "with more attention to thread affinity", it still runs on only one core meaning it won't run any faster because of that, it just runs smoother.

Multithreading is more or less irelevant for game engines since the one thing that takes the most time is rendering and that can't be multithreaded on consumer hardware in any realistic way, today anyway.
Preprocessing can and should be multithreaded, but in reality this still take so little time in comparison to the rendering it's allomst irrelevant.
(IE. you need one hell of a AI system to overshadow rendering)
Just take a look at the benchmarks on toms harware regarding the new dual core processors, on more than one occation a single core processor will beat the dualcore ones.
(i like this not to be true since im thinking about getting a dual core myself, but it is)

O and by the way, i think this discussion has gone a bit oftopic, the simple answer to the original question is - no, not yet anyway.

Well you all can see that you are getting off topic.

What I wanted to know is this: How does Quake3 use multithreading in its rendering pipeline *** points at q3 source

But what got me interested more is this: www.ati.com/developer/ gdc/GDC2005_OpenGL_Performance.pdf

at the gdc there was definite talk about opengl and multithreading in practice

P.S.

Im only speaking about rendering pipeline, ofcourse you have to do a sepereate thread for network,physics,ai,etc.