Multithreading
Author
Hi,
With 3 friends from Uni, we're writing a simple 3d game, in c++ and OpenGL. No engine used, as most of them are more complex than this entire project should be :)
I have a general question - is it a good idea to isolate opengl-related functions in separate thread (considering them i/o so "blocking" operations), and put the game logic in other? Or is it the truth, that most of OpenGL drivers are so much optimised, that they'll do the threading themselves, and the i/o operation is asynchronous anyway, therefore adding additional complexity to project is unnecessary. I'd like to point out that we're pretty good with concurrence, so we have no problems with threads. The overall performance is the only issue.
Regards,
akuda
I looked into this a while back,
Along with the complexities of syncing your updates before rendering (which i will gladly not get into), Rendering is usually kept on the main thread and other stuff is put on separate threads. Rendering is usually all done on the graphics card anyways, so multithreading it doesn't really make sense, at least from what i researched that's the idea I got.
Along with the complexities of syncing your updates before rendering (which i will gladly not get into), Rendering is usually kept on the main thread and other stuff is put on separate threads. Rendering is usually all done on the graphics card anyways, so multithreading it doesn't really make sense, at least from what i researched that's the idea I got.
Adding any kind of multiprocessing (threads, fibers, co-processes, etc.) will introduce a lot of complexity to your project.
There are very few slow operations in OpenGL, mostly the operations that read from the graphics system. The few operations that are slow are will be very obvious in your profiler.
For a school project done on a modern PC, none of those operations should be a problem. If you do have an issue with one of them, it will be easier to fix that rendering bug than it would be to fix a bunch of multithreading issues.
There are very few slow operations in OpenGL, mostly the operations that read from the graphics system. The few operations that are slow are will be very obvious in your profiler.
For a school project done on a modern PC, none of those operations should be a problem. If you do have an issue with one of them, it will be easier to fix that rendering bug than it would be to fix a bunch of multithreading issues.
I'm confused; you say you don't to use an existing engine because the project is simple and then go on to talk about using a thread and performance o.O
Using OpenGL on a seperate thread is doable, however as mentioned it adds an increase in complexity (and unless you've done a major system with threads saying you are pretty good with it is probably over stating things a bit) for little to no gain for something uncomplex. Heck, depending on what you are doing the overhead of syncing might well cost you more than you gain from the extra thread.
As for the rules, well they are pretty simple; only the thread which owns the GL context can issue commands to it.
Using OpenGL on a seperate thread is doable, however as mentioned it adds an increase in complexity (and unless you've done a major system with threads saying you are pretty good with it is probably over stating things a bit) for little to no gain for something uncomplex. Heck, depending on what you are doing the overhead of syncing might well cost you more than you gain from the extra thread.
As for the rules, well they are pretty simple; only the thread which owns the GL context can issue commands to it.
Author
Thanks for your replies, that's what I wanted to know. I believe we'll go multithread, as most of cpu's nowadays are multicore.
@phantom
Thanks for your concern - saying that we don't want an engine to "keep it simple" means, that we do not necessarily need 2 rendering systems and 4 methods of drawing shadows, and 11 supported model formats (including XML). We write a game as part of our Bachelors degree to prove that we do actually know how to code, bottom up. And yes, we are good with threads :), and our head coder is a keyboard-artillerist, truly.
The plan is to implement skeletal animation, picking, probably shadow mapping and create a point-and-click something.
The current idea is a game about axe wielding dwarf, riding spiders to kill zombies, as these are only 3 3d models we have right now :D
Regards,
akuda
@phantom
Thanks for your concern - saying that we don't want an engine to "keep it simple" means, that we do not necessarily need 2 rendering systems and 4 methods of drawing shadows, and 11 supported model formats (including XML). We write a game as part of our Bachelors degree to prove that we do actually know how to code, bottom up. And yes, we are good with threads :), and our head coder is a keyboard-artillerist, truly.
The plan is to implement skeletal animation, picking, probably shadow mapping and create a point-and-click something.
The current idea is a game about axe wielding dwarf, riding spiders to kill zombies, as these are only 3 3d models we have right now :D
Regards,
akuda
Cool, good luck with that.
I would suggest not to do the multithreading unless needed, nothing you talk about there suggests that mulithreading will make it magically faster.
if you do multithread stuff, i would make sure you have your pipeline and all that solid, so you dont have to change your threads and logic again and again.
I would suggest not to do the multithreading unless needed, nothing you talk about there suggests that mulithreading will make it magically faster.
if you do multithread stuff, i would make sure you have your pipeline and all that solid, so you dont have to change your threads and logic again and again.
Just as a general note about using multi-threading for rendering: if your scene rendering requires many state changes/draw calls, then it might be beneficial to put your rendering into a separate thread. If you use a smaller amount of state changes and draw calls, it probably won't help very much.
The other thing to consider is what you will do with the other threads. If you put rendering into one thread, you must be planning to put something else into additional threads that can run mostly without syncing the data that the renderer is using.
If you are really comfortable with threads (as you have mentioned you are), you might want to check into building a job based system. This uses the threads as workers and all work is put into batches, and queued up to get taken up by the next free thread. I believe id software did a few presentations about their latest engine using something like this.
The other thing to consider is what you will do with the other threads. If you put rendering into one thread, you must be planning to put something else into additional threads that can run mostly without syncing the data that the renderer is using.
If you are really comfortable with threads (as you have mentioned you are), you might want to check into building a job based system. This uses the threads as workers and all work is put into batches, and queued up to get taken up by the next free thread. I believe id software did a few presentations about their latest engine using something like this.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
