Original Post
OK, so in another thread it was put forth that one of the things OpenGL would 'fall over on' was its lack of Multi-thread support. Now, we already had some small discussion on this in that thread, however as it was off-topic I figured I'd start a new thread and see if we can get some other peoples input on it. Note: This is purely about the graphics API, not a game engine or games in general, as Oluseyi said Multi-threaded game programming is coming, and it will be everywhere soon. Get ready., which I fully agree with and totally see the point to doing. So, anyone who starts wandering off along the lines of 'you can do multiple engine tasks at once' should be removed from the convo and shot for not paying attension, ok? So, my point of view on this is that while having a reentrant API is 'nice' in that it allows you to render from 2 or more threads at once without worrying about it, for anything beyond simple tests I submit that its not very usefull. Graphics card are inherently state based systems; you set something and its set until you change it and its a well known fact among graphics programmers that in order to get the best possible performance you need to keep your state changes to the lowest minimum, so that the graphics card doesnt have to keep flushing pipelines and generally stalling all over the place. This means that you need to perform some sort of sort to ensure that you dont set redundant states. Now, in a single drawing thread world this is easy, you set the state and you draw, happy in the knowledge that until you tell it otherwise the state wont change magically behind your back, you are happy, the graphics pipeline is happy and all is good with the world. Now, in a world were you can have two or more threads drawing at once things get a bit sticky. This is because in theory the state can change at any point between drawing calls, it might not ofcourse but you cant rely on that. So, something somewhere either needs to track the state and save it (as pointed out to me a way of doing this exists in D3D and also exists in OGL just not in one function call), a job which can be done by the graphics API or the calling application. Now, if its done via the gfx API you pay for the cost of this save/restore everytime you use it (well, unless you have a function which tell it 'this is going to be used via MT' so it sets an internal flag), however by contrast if you move it to the calling application you have to come up with locking routines etc to ensure things cant stamp over your state before you are done with it, at which point what use is a reentrant API if you have to do a load of management yourself? (not to mention the pointlessness of getting stuck in a mutex or other control block while you wait for a thread to finish up) So, lets assume the API takes the first route of the API doing the management and lets assume you can tell its going to be working in an MT system where any thread can render to it. The state tracking still has to be applied, at which point you run into the cost of state changes. Even with just two threads rendering 15 objects (with 10 in thread 1 and 5 in thread 2) there is a chance of at most 10 state changes (I'm assuming the API is smart and tracks state chances sanely, so if the state hasnt change it wont try to change it back again), which depending on the states could be nowt more than a slight blip to a horrible waste of time. Ofcourse, you could wrap both drawiing routines in a mutex or other MT sync system but then you lose your advantage of being reentrant again. With all this taken into consideration I fail to see how being reentrant is an advantage, the cost of state switches and the nightmare if must be for the driver writers to handle it just make it look like more of a problem than its worth. thoughts? comments? agree or am I completely off base here?
