Multi core processor support in CoD
 

With multi core CPU's being made for some time and relatively inexpensive, is CoD designed to take advantage of it?

This is more then asking generic system specs, but some performance detail, since Intel now makes several versions of its iSeries chips in dual and quad core. And then AMD has tri-core.

(If this was asked before I have not seen it.)


A bit of a different question, is it the publisher (UBI) deciding on the system specs and not 1C? If it was 1C, wouldn't they have said it already?

no multicore support, they were too busy working on DX8 support.

Sorry, I know I'm not funny.

Yes there will be multicore support. I believe it's been confirmed (search).

Expect system specs will be given to Ubi by 1C but as the game isn't finished and 1C are doing heavy optimisations they can't give specs till it's done.

I think (not 100%) but the last few weeks and months the Devs spend bug fixing, optimising like crazy and this is usually when they can lock down the specs for gold.

I expect a Dual will run it ok, till you get lots of stuff going on (lots of other aircraft) and a quad will be better. Ram you want to be looking at 4GB reall and Graphics a DX11, 5850 a good starting point.

Please note, these are no way accurate as no one really knows yet. Just ball park guestimates.

Ilya has announced on FB that they'll be releasing system specs soon.

FB?

Facebook.

http://www.facebook.com/home.php?#!/il2sturmovik

Wow thats very good to hear!

I wonder if we can monitor the rise in HW sales hours after the official system spec announcement? ;)

lol facebook. :)

Still - excellent news.

Great info, thanks!

OMG!!!
Facebook EXISTS!! (tweets to friends)

I thought it was just a movie!!1!1one!!





;)

Of course they will have dual core support, standard is 4 cores now, by 2012 will be 6 or 8 (high range 32nm intel and the new AMD Bulldozer). Not that this is 8+ threads since each core is also 2 virtualy cores. So real question is will they support hyperthreading?

Hopefully the engine can be edited so that it works on hexa and octacore efficiently.

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?

You have an attitude that's really starting get boring. Yes I maybe lied a bit - the last 5 years I've been manager of a development department at a company that has done high preformance multi threaded code since 1994. Thereby I have not been programming 12 hour a day like before. You lack of knowledge about c/c++ really shows as it is the language that most multi threaded applications are written in (like Windows 7 ;)). It's obviuos that you don't understand what a thread is and how they are created so discussing this feels like talking programming with an 18 year old that has done some "web programming"...

I will not continue this discussion so please don't paste more text you don't understand from wikikpedia/tomshardware.

Why did I really feed this troll? I usually manage to restrain myself from that.

PS. Send me you linked in profile in a PM and I will send you mine if you promise to not post it further. I really like to be able to participate in forums like this without using my real name as I don't want to mix my private interests with my business profile....

Offtopic:

Although multicore and multithreaded cpu's are relatively new, multiprocessing dates back to the mid-fifties. Already in 2000 I had a dual Pentium II machine running NT4.0, Linux and Solaris (not at the same time, mind you). They all made use of both CPU's. It's remarkable that it has taken such a long time to come up with the idea of multicore/threading and that programming them still is a problem.

A fine example of early custom chip (multi)processing was the Amiga, where already in 1985 the chips Agnus, Paula and Denise did work for the 68K CPU to produce graphics, sound, control I/O and memory access. Agnus essentially being the first ever successful GPU and DMAC and sometimes even controlling the CPU and being able to manipulate graphics without using CPU cycles. Programmers didn't even need to use the multitasking kernel.

Had programmers and hardware designers of the x86 platform taken a closer look at the way the Amiga solutions were implemented, these things would've been easier a long time ago.

Someday I'm going to be wrong! But not today!

Nope - but it was open goal ;)

Wait, I am the troll? You just admited to lying and I called you out on it. Therefore I am the troll? You then result to personal insults based on no substance (all you are saying is, you dont understand the programming, you must be 18 and a kiddy, therefore I my argument is correct because I can demean you, inflate myself and try to be intimidating). Again Ad Hominem attacks... Does calling me 18 and saying I am wrong without providing one shred of evidence/proof/info really prove your point? I never said C++ cannot programme multi threaded apps, I quoted the wiki there about its native abilities but more to outline the point about the 20 yrs. I called BS on your claim of experience due to the length of time and other things you have said. You have still not addressed any of my points though, dont bother replying because it is obvious you dont want a discussion/debate here because you got caught like a deer in the headlights. Also I am not a professional programmer, never claimed to be, I do know a good deal about hardware and its interactions with software though.
Btw never done any web programming, but its sad you cant hold up a argument vs a 18 year old...

Like I said - please PM your LinkedIn profile and I will give you mine if you doubt my claims of experience. Now let's quit this argument that will lead nowhere.

I dont give a damn about your experience whether it is true or false (well we already know something about that I guess). I do give a damn about you bsing me and saying I dont know what I am talking about, but you are not able to give a coherent or even articulate an argument / point to contest my observation with. I will not be contacting you so that you can save face, sorry.

I havent coded in like 20 years, but mazex is spot on. People who think creating a game engine that can make proper use of 2/4/8 or more threads is easy need to do some reading. There is a reason most software today barely scales beyond 2 threads. Heliocon, maybe you should just try it.

What I am curious about is the physx claim, that it would be useless for flightsims. I dont know about the API, maybe that is useless, but calculating the physics (rather than PhysX) does seem something that could benefit greatly from GPGPU (CUDA or OpenCL).

OK - please calm down. Let me try to explain what I mean then...

Well, I did write a long example with pseudo code and all in my second post in this thread but deleted it as it was to long winded. I realize that you actually think you are right and then naturally think that I'm just talking bull so let's try to sort this out then.

I think that the problem is that you have maybe confused threads and cores in some way. When you write a Windows program it will run in a process and if you do no not create more threads yourself in the code it will just run on a single thread. That thread in it's turn can only run on one CPU or Core (and the OS assigns that if you don't mess with that yourself which really should not be done) . So a game that does not create additional threads will run on one core... It will do calls to the OS that will use other threads for that but generally it will just load one core itself. Then to use the other cores you have to create new threads from your code and start them yourself in the code. The OS can then let them run on one of the other cores or CPU:s if available or chop the time on the CPU between the threads if you have only one CPU/Core. OK - so the threads run in the same process but one of the problems is that if they are going to access shared memory (variables like the state of the me 109 in front of you) they may try to update the same shared memory (like an array of detected enemies that is a private variable in the CFighterPlane object) and that's a no no. Therfore you have to make sure that the thread that is going to update that shared variable get's exclusive access to the variable while updating it - which is essential if you are going to write thread safe code (handled by identifying these critical sections and make sure to exclusive access that memory while updating it so no other thread does that at the same time). The problem is also that both the AI thread (if you create a thread for that in your code and the OS then assigns that thread to run on a core.) and the code for the Collision detection might want to update the number of enemies detected by that specific enemy plane object as the collision detection code has just "killed" that same enemy plane that crashed into a mountain in classic IL2 way ;) The AI code is then on the same time trying to update the object that got "killed" to try to avoid the mountain. What happens then? Those problems are really hard to debug in multi threaded code as opposed to traditional single threaded code that can be debugged line for line but the in the multi threaded code your breakpoint at the part of the code that detected the collision will stop but what is the state of the other thread? Those problems are hard to solve and if your AI thread is milling along updating the "inputs" for the AI planes the render loop has to know that as it updates the actual meshes loaded to the GPU each loop in the main game loop. Not trying to push you down but trying to explain - OK?

/Mazex

Hey, why dont you read my bloody posts before you comment? I never said it was easy, I infact said it was hard to do. Dont put words in my mouth. I took issue with his definitions of memory which are factually incorrect.

Also physx (which I never mentioned btw as someone implied I did) is mainly geared to particles and cloth/hair etc. It would certainly work for stuff like clouds and smoke that interact with planes passing through, but I dont know of its effects on flight models. CUDA is meh.

Good explanation. I understand what you are saying and it does indeed seem like a plausible problem. The one question though is when you say memory, what are you refering to in the system? Is this cpu cache? It may be harder to program but parallel processing is still faster then serial, even if it may be more difficult to work with (I would argue that its more of an issue with people adjusting to the new "format" and that over time it will become much easier.)
I understand the differance between threads, cores, processes etc

Also the reason I hate programming is debugging because I accidently put a comma or a mistype somewhere and the whole damn thing goes nuts and spams me with errors and I cry into my keyboard as I spend the next day going through 1 hour of code to find the mistake :rolleyes:

Good that we have normalized the situation then :)

No - that memory I'm talking about is just the RAM memory that the threads share and that is allocated to the process and it's subthreads by the OS. That memory is then divided into the stack (variables, structs etc - normally with short lifespan that is "cheap" and fast) and the heap (where objects etc are dynamically stored for a longer time and you allocate and deallocate that memory yourself (and it is slower than the stack)). This is all stored in RAM unless the OS decides to swap it to disk if it runs out of memory (but you are fine with your 12 GB ;)). The fact that the CPU then uses registers (memory) etc is something a "normal" programmer never mess with in normal cases with modern programming languages....

If you did not like debugging straight single thread code you can imagine doing that in multi threaded code with eight threads messing with each other and you don't really know the state of that 109... Is it dead or alive? The CollisionAndResponse thread thinks it is not but the AIThread does not know that so can we call it the opposite of brain dead? ;)

Particles is what its mostly used for, for obvious reasons: many (/most) gamers dont have physx enabled hardware, therefore its used for eye candy that can easily be turned off without affecting actual gameplay.

That doesnt mean its not usable for physics simulation like aerodynamics. Surely you've seen all the hydrodynamics simulations. If it works for water, I dont see why it couldnt work for air:
http://www.youtube.com/watch?v=ok8ThRR-59Q

Bravo, mazex! I applaud your patience and the clarity of your explanation!

Thank you for the responses Maze, I know my tone can be abrasive but I am not looking around to pick a fight here. The issue with the ram was I thought you were talking about the CPU cache (for example i7 uses two 4mb cache's, 4mb for 2 cores/4 threads). This is what I was trying to get at originaly, the conversation then nosedived, so from my view I was arguing about hardware allocation. But yes again I never said multi threaded programming was easy, just that it was necessary since clock speeds are not increasing like they used to.

Anyway thanks for the polite and well thought out responses, but be wary my eye in the sky is watching for you to make a minor grammatical error so I can wtf divebomb you and call you an old fart who programmed typewriters for 20 years :o

No reason that I know off, I just dont know how they manage the flightmodel/air interaction. If there "zones"/boxes of air with different property? So If I enter one area I get turbulence or something? Or is it managed dynamically or prodcedually? I have no idea tbh

The main difference is Physx is not really a mechanic focused on physics as much as it is focused on solving and then "presenting" the effects. Its also GPU tied which needs to be rendering. Physx is great, but unless you have a dedicated card its better to buy a second card then have a non physx gpu. Atleast thats what people seem to think on the EVGA forums.

Well air is compressible, water is not ;) PhysX is primarily designed for rigid body physics (the water animation also belongs to that area) and not too useful for more complex problems, although I have to admit I'm not sure what the most current state of the API is.

The bigger problem though is this: the flight dynamics engine is the core of any flight sim. You cannot rely on proprietary solutions like PhysX because you have to make sure it works for everyone, and also the same for everyone. It is much harder to debug, it is additional work even if only parts of the calculations are moved to the GPU and you run the risk of ending up with a dead solution should nVidia decide to drop it one day or maybe go out of business.

[QUOTE=The Kraken;217731]Well air is compressible, water is not ;) PhysX is primarily designed for rigid body physics (the water animation also belongs to that area) and not too useful for more complex problems, although I have to admit I'm not sure what the most current state of the API is.

The bigger problem though is this: the flight dynamics engine is the core of any flight sim. You cannot rely on proprietary solutions like PhysX because you have to make sure it works for everyone, and also the same for everyone. It is much harder to debug, it is additional work even if only parts of the calculations are moved to the GPU and you run the risk of ending up with a dead solution should nVidia decide to drop it one day or maybe go out of business.[/QUOTE

Yep I agree, I dont think physx should be in because it hurts ATI users, they need to come up with a standard system, but I dont think Havok will cut it either (specially not for flight modeling).

Actual calculation of airflow over a plane wing and prop is probably many years out. That stuff is so compute intensive super computers struggle with it and may not do it in realtime.

I do remember seeing a video of Rise Of Flight where air movement was visualized with arrows, showing wind, prop wash, thermals and the like. I cant find the video, it was really impressive, and showed that game is modelling airflow to some extend (though probably not to calculate aerodynamic behavior of the plane). I was just guessing stuff like that could be offloaded to the GPU.

As for PhysX as API, I was talking more generally about GPGPU. There is also OpenCL which works on both ATI and nVidia cards.

PThanks, and I'm sorry I had a tough attitude too when replying first. As seen here that just escalates an argument which is in most cases built upon a misunderstanding of what the other person is saying and that we then think we understand what they really think ;)

And regarding typewriters I don't have that (yet ;)) in my cv after many years as a software consultant. The most "boring" project I've been on must be climate control systems (not the small ones for cars), but then again - programming is never boring once you get over the first frustration while learning to write thread safe code for example...

Thanks! :)

OK - I understand. If you now get the concept I described that the programmer has to create threads himself or everything runs in one thread etc, then read the wikipedia article about Hyper-threading which I think is what confused you (and many else!):

http://en.wikipedia.org/wiki/Hyper-threading

So in a hyperthreaded CPU the OS thinks it has two CPU:s (or cores - whatever). It can then run the main game loop thread on the first one and the AI thread on the other (from the previous example). The problem (or finesse) is then that the CPU uses it's registers and fat cache to internally switch between the threads without the OS having to care or do that as the CPU has better and faster knowledge about when there is a "slot" of idle time in the game loop so the AI thread can get access to the actual CPU (which is only one). This does not fix the problem of knowing if that 109 is dead or alive though as the two threads running on what both the OS and your code thinks is two really CPU:s don't get any help from this - and they have to be written just like a normal multithreaded application... And if one of the threads constantly uses the single CPU that other thread will not get any cycles to the CPU has to force it into wait and give some CPU time to the AI thread... Therefore HT can be good in some cases but as it's really a smart way to fill available slots of excecution time - but there is really only one "brain"... :)

Let this thread be a sticky on how you can resolve arguments without flinging crap at each other. Very well done gentlemen! I also applaud you :grin:

I know about hyperthreading (cores vs threads etc).
I wonder how different bulldozer will be interms of programming for it. Havent heard a huge amount on it tbh.

So far I've seen an argument or two, some speculation, but nothing from anyone that counts.

I like to see an official statement as to whether or not multi-core processing is supported.

Just a simple yes or no.

Is that too much to ask?

Oleg has previously said that the code would be multi threaded, but to what extent is unknown to me at least...

Given that dual core chips are minimum requirement and quad core recommended, it safe to assume it makes use of (3 or) 4 threads.

I coded multithreaded apps for macos in 1989. In my perception no grafical user interface can exist without multithreading. Ever tried to programm a progress bar without it?

I'm glad you all sorted out your problems, I was just about to get the wifey to kick the stool out from under me and end it all, I just hope the game works without stutters, I will leave the reasons as to why it runs smoothly for you guys to explain. :rolleyes:

Oh by the way I'm huge and muscular and will be kicking all your arses if you start any more mind numbing posts on multi threading etc.;)

I say settle it over the English Channel like real men!