Well, if they manage to balance 4 threads that really does something useful and don't spend too much time on synchronization/sleep/wait/join so the main render thread can not continue they can start thinking of that ;) Multi threading is good for a lot of stuff but in a game where the game render loop runs at 100 fps you can't wait 10 ms for some shared memory that is locked by the AI thread that is busy or you will get problems... Ok, for some tasks like loading data or textures in the background that does not mess with shared memory it can be useful but to spread ai, physics, net code etc on different threads and really gain performance you easily end up with code that is a pure hell to debug or tune... Multi threading works best for stuff that does not share stuff - like in a business application where one thread can chunk tasks that run for a while with no interaction with the other threads and then return a result. Thats not how a game works unfortunately...

uhhh what? Sorry you got the mechanics here very wrong. First off the CPU does not render anything, thats the GPU. Second shared memory.... lol?
3. I think you misunderstand the mechanics of how threading works, it activly assigns tasks to each thread, it does not "lock them" to one task. If it does thats extremely poor programming and will not be present due to the fact that it would most likely be incompatible with W7+DX11 dynamic load management. The threads are not assigned like AI, Physics etc, they just all run tasks in parallel, often they will run constantly one area of the game but the whole idea of multithreading is to eliminate the wait. In a singlecore/thread it has to do AI+Physics+etc+etc all in single pieces and rotate, multi threads eliminate this completely.

Anyway again there is no shared memory when you refer to textures etc. Thats GPU ram and is seperate from your volatile Ram, your CPU Cache, and your HD cache. Unfortunetly it seems games do not run the way you think they run...:rolleyes:

*oh btw edit: most / many modern Mobos have integrated network chips, even if not they use very little ram. My intel 980x has 12 threads, I challenge COD to use that. The result is I can have 5 cores/10 threads dedicated to the game at 3.3-4ghz, and have the last core run win7 + steam + networking / whatever else in the background while the rest is completely dedicated to the software.

Well, I've done multi threaded c++ programming for 20 years and I have a feeling you have not? Never heard of shared memory and locks? Think the threads create themselves? C'mon...

+1

Designing a game engine to make full use of large numbers of cores is a nightmare that no developer can afford, Physx is completely useless for flight model calculations, and a graphics engine that runs entirely on the GPU is a pipe dream. All those expectations are probably based on CPU & GPU vendors' PR, who like to make fantastic promises that developers are supposed to fulfill. As usual, real life is a little bit more complicated:

http://spectrum.ieee.org/computing/s...th-multicore/0

Bracing for longwinded copy+paste from Wikipedia/Tomshardware. ;)

Teehee :D

Resulting to an argument from authority is pretty weak. I have done some Java programming, in fact I created Java... Its the internet - your credentials cannot be verified so this makes me lol. Go wiki Logical fallacy.
Oh and yes, I also extensivly used Maya 7.5 for modeling geometry, texturing (which I suck at) and animation (which I also suck at). Thats the truth, but it does not matter as your argument here should be based on what you say and facts.

You are most likely bsing, you have been programming multi threaded programs for who? 20 years? Please enlighten me to your credentials or the company you worked for. Otherwise I call BS because multi threading is relativly new. Also your statement on memory locks I have already addressed and is incorrect. Must not be a great programmer, locks were used in single threads to prioritise threads for the cpu, NOT in multi threaded systems (they can be used but are no longer used in newer multicore OS's as they used to be).
I never said it was easy to programme, it is in fact very hard. What I did say is that what you said is wrong, so are you going to explain your statement on shared memory or not? You specifically discussed graphics processing being run through the CPU and its Memory which is completely false. What shared memory are you talking about? I already asked this but you didnt address the question. Are you talking about the system Ram, GPU ram, CPU cache?

I dont think you know much at all about the programming tbh, just because a computer has more then 1 thread does not mean it is parallel, you could well of used multiple threads before which memory locks were applied to in order to prioritise a thread (which like I said in the first post was the cpu jumping to multiple threads in succession but it could only process one at a time). Again this is eliminated.

Maybe you meant you were programming 20 years ago? That seems more inline with your post...

Oh lol I just found this, I thought something was fishy: http://en.wikipedia.org/wiki/C%2B%2B
"Other criticism stems from what is missing from C++. For example, the current version of Standard C++ provides no language features to create multi-threaded software. These facilities are present in some other languages including Java, Ada, and C# (see also Lock). It is possible to use operating system calls or third party libraries to do multi-threaded programming, but both approaches may create portability concerns. The new C++0x standard addresses this matter by extending the language with threading facilities."

Lower area of Wiki article - owned...

Wait is this in response to me? I havent mentioned PhysX in the thread that I am aware off...
Graphics engines do run completely on the GPU, a graphics engine doesnt mean the entire game, a graphics engine renders and creates the geometry and textures etc.

<picks a comfy seat and settles in with popcorn and Fanta>

Its my bedtime, have to sleep now :(

Can I have some popcorn first though?