How many CPU-cores will be supported in future by EDGE?

I think you've misunderstood.

Um, no, he hasn't. But whether what he says will really ever happen is anybody's guess of course :P

Why do people ask the questions that have been answered? Wags looked into multi CPU threads and said the gain is minimal. Its then re-quoted briefly above.

I don't think anyone has misunderstood, but they certainly don't read well.

I had the choice of CPU years back and a little reading I came up with the Sandybridge i5 and overclocked it. It's based on common sense and testing, but the advice is all out there.

Do it when you feel it's time.

Computer upgrades cease for no program!:music_whistling: As we have seen in DCSW alone, if one waits to take advantage of new tech only when an all applications can make use of it, we would all still be stuck with Atari's.:D

Seriously, if you think your current system is overdue for an upgrade and you have the funds, just go for it. ED is working to give us a gem, and no one outside the "loop" have much of a clue what the system demands will really be.:dunno: My guess is that after they do release 2.0, we will be reading a lot of threads regarding optimizing systems for it. If one has more money than patience, then it is ALWAYS beneficial to have the latest and greatest.8)

Um, no, he hasn't. But whether what he says will really ever happen is anybody's guess of course :P

 

Some features we plan to include in DCS World 2 include:

• Direct X 11 support
  
• Improved performance
  
• Dynamic shadowing of the terrain and mountains
  
• Improved weather
  
• Improved lighting
  
• Clipmap support for new maps
  
• Higher object counts
  
• Higher resolution ground terrain mesh and textures for new maps (between 1 and 64 meters per pixel depending on area of map and clipmap level)
  
• More detailed tree models with collision for new maps
  
• Better graphical effects
  
• High resolution road textures for new maps
  
• Ability for road signs and light signals for new maps
  
• Additional ground clutter (rocks, cactuses, etc.) for new maps
  
• Skeleton animation for infantry
  
• Better use of multiple GPUs (CPU multi-threading is not being pursued as it will provide little if any gain)
  
• Ability to create dedicated servers in the future
  
• Unified front end and simulation .exe
  
• Improved API sound support
  
• Improved Oculus Rift support
  

Please don't do a bad favor to those who have not dug into the whole DCSW 2.0 thing yet. Unless you have source to back your claim.

Unless you have source to back your claim.

I didn't state a fact, i stated my opinion and clearly declarated it as such. Get off my back.

I didn't state a fact, i stated my opinion and clearly declarated it as such. Get off my back.

I thought quoting msalama is enough to indicate that I'm replying to msalama. Your post looked like an opinion so all is fine but his post didn't.

EDIT:

Besides, information on the forums is scattered. It was also my request for a link if he saw such information somewhere. No need to interpret a post the worst possible way.

Dev here...

At first I'm also looking forward to DCS 2.0 and all the new stuff.

I try to give an answer why it's not easy to get a faster game engine by just adding more CPUs to the computer. In software development an additional CPU is not like an additional turbine on a jet. An additional available hardware thread doesn't just scale linear. This is due to the nature of the fact. It's more like you have ONE knife and plate in the kitchen and try to prepare two salads by adding a second person in the hope this will be faster. You have to share your knife and plate, clean it in between the sharing, store the salad somewhere.... well strange example. But it somehow explains the problem of resource sharing (knife/plate) and multiple threads (persons).

The game engine has to be designed around multi-CPU. That said it's not always easy and efficient to just split the algorithmic tasks (example above) for multi-CPUs. The facades of the engine must be suitable for multi-CPU. So you could have one thread per scene graph traversal, object sorting, physics simulation, sound, data streaming from storage (landscape) for example. All theses tasks are suitable to be handled by a specific thread (hardware thread).

And then there's the GPU. Currently every mainstream game/engine in the industry is build around potent GPUs... multi-GPUs. GPUs are designed to do really... really... r... fast raster graphics based on tringales. So at the moment in the area of graphics the only task of the CPU is to feed the GPU(s) with data (triangles, textures, shaders) in the most efficient way. Well of course we have multi-thread access to the GPU since DX11. But you would have todo a lot of stuff so that one hardware thread becomes a bottleneck for the GPU.

GPUs on the otherhand are designed in a SIMD fassion. (single instruction multiple data => e.g. a single shader (kernel/instruction) transforms multiple vertices (data)). So they run many kernels (by shader units) in parallel on your data. Due to this fact you can just put one additional GPU in your system and it scales to some point because of more available shader units. But there're problems too. The GPUs also have to share data... ;)

Until DCS 2.0 isn't released it's pure speculation how the engine is designed. You can do a lot of stuff if you have time and money. But the cost-benefit ratio must be given. In this sense Wagss statement: "CPU multi-threading is not being pursued as it will provide little if any gain".

Cheers

Dev here...

 

At first I'm also looking forward to DCS 2.0 and all the new stuff.

 

I try to give an answer why it's not easy to get a faster game engine by just adding more CPUs to the computer. In software development an additional CPU is not like an additional turbine on a jet. An additional available hardware thread doesn't just scale linear. This is due to the nature of the fact. It's more like you have ONE knife and plate in the kitchen and try to prepare two salads by adding a second person in the hope this will be faster. You have to share your knife and plate, clean it in between the sharing, store the salad somewhere.... well strange example. But it somehow explains the problem of resource sharing (knife/plate) and multiple threads (persons).

 

The game engine has to be designed around multi-CPU. That said it's not always easy and efficient to just split the algorithmic tasks (example above) for multi-CPUs. The facades of the engine must be suitable for multi-CPU. So you could have one thread per scene graph traversal, object sorting, physics simulation, sound, data streaming from storage (landscape) for example. All theses tasks are suitable to be handled by a specific thread (hardware thread).

 

And then there's the GPU. Currently every mainstream game/engine in the industry is build around potent GPUs... multi-GPUs. GPUs are designed to do really... really... r... fast raster graphics based on tringales. So at the moment in the area of graphics the only task of the CPU is to feed the GPU(s) with data (triangles, textures, shaders) in the most efficient way. Well of course we have multi-thread access to the GPU since DX11. But you would have todo a lot of stuff so that one hardware thread becomes a bottleneck for the GPU.

 

GPUs on the otherhand are designed in a SIMD fassion. (single instruction multiple data => e.g. a single shader (kernel/instruction) transforms multiple vertices (data)). So they run many kernels (by shader units) in parallel on your data. Due to this fact you can just put one additional GPU in your system and it scales to some point because of more available shader units. But there're problems too. The GPUs also have to share data... ;)

 

Until DCS 2.0 isn't released it's pure speculation how the engine is designed. You can do a lot of stuff if you have time and money. But the cost-benefit ratio must be given. In this sense Wagss statement: "CPU multi-threading is not being pursued as it will provide little if any gain".

 

Cheers

Thanks for the explanation. Few add. questions (please disregard my misuse of 'core' and 'thread'):

1. Are you a member of ED team or do you work on other projects?

2. Is it that a high-fidelity flight sim is inherently less suited for splitting into multi-threaded tasks compared to, say, a modern RTS game?

3. Since DCS utilizes only so much cores would it be beneficial to set affinity so that the operating system doesn't touch cores assigned for DCS? Is it handled like this in DCS/DCS2.0?

4. "CPU multi-threading is not being pursued as it will provide little if any gain" - Is it related to #2? Would it be entirely different if they had started from scratch today (literally)?

5. Do you personally think the http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/ has a chance of benefiting DCS, ArmA or any other complex sim already released within say 5 years?

I also appreciate Wags has phrased it as he did instead of just saying "No multi!".

@1: No I'm not a member of the ED team. I do other projects... at the moment nothing graphics related.

@2: No. It should be totally possible. But I'm not an expert in flight simulation engine design. But in the end you have: terrain rendering, water rendering, entity rendering, sky rendering, sound rendering (I read somewhere that they use one thread for sound exclusively in DCS 1 for advanded effects like sonic boom, can somebody confirm this?), cockpit rendering, physics, networking... so nothing totally different from other game engines like Unreal Engine, CryEngine, Frostbite and what not. But a flightsim engine have to has a very good scaleable terrain/entity renderer because you have square kilometers of playfield. The DCS 2 demo videos I saw the last week where very impressive. The terrain looked good from every altitude. You even saw curvature of the earth.

@3: The operating system kernel is clever. At least earlier in WinNT and since Windows Vista/7 again. As far as I remember they did a complete new task scheduler for Win7 based on WinNT. Something like this. So the engine, If there're enough hardware threads, could set affinity for heavy load threads which then run exclusively in one hardware thread. I dont know what DCS 1 or 2 does... will do.

@4: Could depent on 2) based on how your game engine works. This topic on it's one is heavy science. You can spent years developing a bad ass engine... see Unreal Engine... Cry Engine... the cost-benefit ratio must be given for this. On the other hand engines like Unreal and Cry are very flexible engines. At least for now DCS is very aircraft concentrated. We got closer to the ground with the helicoper simulations and even closer with Combined Arms. So here things must improve. In the interview on mudspike Waggs mentioned something in this direction. So if you want to drive a tank over detailed terrain or walk soldiers. You need some addional things in your engine.

If they would start today with a new engine the base facts didn't change. Multi-threading is nothing new. The only thing which could lead to an adapated design is the knowledge the developers gathered while developing DCS 2.

@5: Didn't know about HSA. But yeah... the text content is not that new. At first we had GPUs which where fixed to rastering triangles. You had some register combiners to manipulate color. Transformation, Clipping, Lights and fog where baked. Then the vendors realized that it's better to have a more general GPU design. So the (nearly) general purpose GPU architecture combined with shader languages where born to be able to write SIMD kernel (vertex-, pixel-, geometry-sahder) for the GPU. This indead ended in CUDA and at the end in OpenCL. We created a parallel universe CPU | GPU. Companies tried to give developers tools at hand to utilize the amount of available CPU hardware threads with libraries like Intels Threading Building Blocks. The HSA article to me sounds like the next stage of Intels Threading Building Blocks. Yeah games will profit from it. But the developers have to adapt. For example on a playstation this kind of heavy multi-core programming is standard.

...

Thanks for your input.

With ED quitting on 'multi-core' I hope ED squeezes everything out of the remaining optimizations including affinity handling.