Attention GG Employees! Is the shader engine multithreaded?
by Afrim Kacaj · in General Discussion · 01/10/2006 (8:40 pm) · 8 replies
It seems that the world of processors is moving to dual core. I am not aware of any games that are currently able to take advantage of dual CPU or Dual Core systems.
I understand that given the nature of games being that everything has to happen in real time and the dependency of the next step on the last makes it difficult to implement. However the idea still bothers me given that torque works in a client/server manner.
Is it not possible to have the client run as one thread and the server run as a second thread and have each thread run on a separate processor. The server handles the collision and game logic while the client handles the rendering etc. Wouldn't multithreading effectively split the work of the engine in half? One thread for each processor and would allow the developer to use more detailed, collision, polys on the models etc.
Xbox 360 has three cores, how is that going to work?
Since the Shader Engine is still in the works wouldn't this be a great time to implement it? Throw 64 bit in the mix and we may have our hands on one of the fastest game engines in town (or at least in theory)!
I understand that given the nature of games being that everything has to happen in real time and the dependency of the next step on the last makes it difficult to implement. However the idea still bothers me given that torque works in a client/server manner.
Is it not possible to have the client run as one thread and the server run as a second thread and have each thread run on a separate processor. The server handles the collision and game logic while the client handles the rendering etc. Wouldn't multithreading effectively split the work of the engine in half? One thread for each processor and would allow the developer to use more detailed, collision, polys on the models etc.
Xbox 360 has three cores, how is that going to work?
Since the Shader Engine is still in the works wouldn't this be a great time to implement it? Throw 64 bit in the mix and we may have our hands on one of the fastest game engines in town (or at least in theory)!
#2
01/10/2006 (10:43 pm)
TSE's new terrain engine, Atlas, is streamed from hard disk in a seperate thread.
#3
01/11/2006 (6:36 am)
Jason if something is wrong with my logic then please explain! if we all went the insult route this forum would be useless.
#4
multithreading is not an easy problem to solve.
it's all well and good that you ask for something, but not knowing how to solve this problem yourself, in your own game, means that:
first, you wont appreciate how difficult of a task multithreading is, and:
second, you wont realize that Josh's answer is basically "no it is not multithreaded" and:
third, even if the 'engine' is multithreaded, you wouldnt be able to fully take advantage of the fact, because your game logic will dominate the performance times anyway (due to your game logic not being multithreaded).
Sorry i'm being a bit crude (i've been up for the last 20hrs) but a multithreaded engine isnt a panacea... it's a good thing to have, but having a good methodology for asynchronous programming is what's REALLY needed, and unfortunatly programming languages have a LOT of catching up to do.
01/11/2006 (7:08 am)
I'm not insulting, it's a valid point i'm trying to make.multithreading is not an easy problem to solve.
it's all well and good that you ask for something, but not knowing how to solve this problem yourself, in your own game, means that:
first, you wont appreciate how difficult of a task multithreading is, and:
second, you wont realize that Josh's answer is basically "no it is not multithreaded" and:
third, even if the 'engine' is multithreaded, you wouldnt be able to fully take advantage of the fact, because your game logic will dominate the performance times anyway (due to your game logic not being multithreaded).
Sorry i'm being a bit crude (i've been up for the last 20hrs) but a multithreaded engine isnt a panacea... it's a good thing to have, but having a good methodology for asynchronous programming is what's REALLY needed, and unfortunatly programming languages have a LOT of catching up to do.
#5
I didn't think that it would be an easy task and I guess I did not give it a deep thought. Obviously I know that GG staff is way above my level in programming and that they probably thought about this a million times.
To implement it into my own game, well let's just say that my graphics have a lot of catching up to do before I even think about it.
Your explanation makes perfect sense to me. But I would still like to hear other opinions, it was tough to go to the moon but it has been done!
01/11/2006 (7:45 am)
Sorry Jason I took it the wrong way :(I didn't think that it would be an easy task and I guess I did not give it a deep thought. Obviously I know that GG staff is way above my level in programming and that they probably thought about this a million times.
To implement it into my own game, well let's just say that my graphics have a lot of catching up to do before I even think about it.
Your explanation makes perfect sense to me. But I would still like to hear other opinions, it was tough to go to the moon but it has been done!
#6
I think they are
1. Aware of the situation and new hardware.
2. Aware that a new MS OS is coming out this summer that is tuned for the SMP MCM modules (multi core cpu packages).
3. Working on more fundamental issues with TSE at the moment.
So it's on the radar but not on the plate I would guess IMO**.
I do plan on buying a dual core once the 65nm cheaper models come out (non extreme edition) so this is an issue I am interested in as well.
01/11/2006 (8:31 am)
There is a public TSE forum btw...I think they are
1. Aware of the situation and new hardware.
2. Aware that a new MS OS is coming out this summer that is tuned for the SMP MCM modules (multi core cpu packages).
3. Working on more fundamental issues with TSE at the moment.
So it's on the radar but not on the plate I would guess IMO**.
I do plan on buying a dual core once the 65nm cheaper models come out (non extreme edition) so this is an issue I am interested in as well.
#8
That is not to say you can't use threads. If, and only if, you have experience writing and debugging multithreaded code, there are some options available to you. Please read this TDN article for information on multi threading in TGE 1.4.
Why am I mentioning TGE 1.4 when you're asking about TSE ? If you need threads (which you probably dont, but thats a seperate issue) then TSE is not fully upto date with the thread safety fixes from 1.4. Hopefully that will change soon, but for now you'd have to merge TGE1.4's console, platform layer, and possibly core (I forget without checking) to TSE. This isnt too tricky, but requires merging a fair bit of code.
So, in summary, if you know what you're doing, yes there are options for multithreading. No, TSE/TGE/T2D itself does not take advantage of threading, with a few small exceptions.
T.
01/11/2006 (12:48 pm)
No version of TGE is truly multithreaded in the sense that the game engine itself uses threads. TGE is, and more then likely will be for the forseeable future, a single threaded app. There are some exceptions, as somebody mentioned, Atlas uses threads. So does the new Theora control in TGE 1.4.That is not to say you can't use threads. If, and only if, you have experience writing and debugging multithreaded code, there are some options available to you. Please read this TDN article for information on multi threading in TGE 1.4.
Why am I mentioning TGE 1.4 when you're asking about TSE ? If you need threads (which you probably dont, but thats a seperate issue) then TSE is not fully upto date with the thread safety fixes from 1.4. Hopefully that will change soon, but for now you'd have to merge TGE1.4's console, platform layer, and possibly core (I forget without checking) to TSE. This isnt too tricky, but requires merging a fair bit of code.
So, in summary, if you know what you're doing, yes there are options for multithreading. No, TSE/TGE/T2D itself does not take advantage of threading, with a few small exceptions.
T.
Torque Owner Jason Swearingen