Civilization: Beyond Earth the next Mantle game.

[bystander36]

This comment is just an oxymoron. A relevant part of an API having low CPU overhead is to actually be multithreaded. Unless the OpenGL groupies think that reducing the CPU overhead involves pixie dust and black magic, spreading the workload evenly across threads is a key component in making an API with low CPU overhead.

No, you got that wrong.

Low overhead is not the same thing as multithreading. Both matter, but both help in different ways. Low overhead reduces processing time of a draw call. Any draw call, whether it is single thread or multithreaded. Multithreading allows the process to use multithreads and cores of the CPU, allowing it to scale better as CPU's add more cores to them.

Both matter. I think long term, multithreading is more important, as CPU's have hit a wall on single threaded performance. Adding more cores has a lot more potential in the future.

 

[Gloomy]

So is an overhaul on the level of DX12 on the horizon for OGL? Or are they going to let DirectX try multithreading twice before they give it a shot once?

 

[3DVagabond]

Mantle isn't coming to Linux.

OpenGL already has ways to reduce driver overhead that is supported by the big three. It can't do multi-threading though, it will need a rewrite for that.

We'll see.

http://www.planet3dnow.de/cms/5720-apu13-andersson-will-mantle-fuer-alles-und-jeden/

It won't come to linux? If it came to linux Mantle would have a HUGE advantage over direct x. Looks to me like AMD sure knows that.

Agreed. Seems like AMD would be really dumb to tie themselves strictly to an OS that was owned/controlled by the company who writes the competing API.

 

[PPB]

No, you got that wrong.

Low overhead is not the same thing as multithreading. Both matter, but both help in different ways. Low overhead reduces processing time of a draw call. Any draw call, whether it is single thread or multithreaded. Multithreading allows the process to use multithreads and cores of the CPU, allowing it to scale better as CPU's add more cores to them.

Both matter. I think long term, multithreading is more important, as CPU's have hit a wall on single threaded performance. Adding more cores has a lot more potential in the future.

I think your reading comprehension skills are at fault here. Did I ever said they are the same? Hint: the correct answer is not "yes"

I just said that multithreading is KEY into making a low CPU overhead API. No matter how thin is your driver or how low level can your API be, if it isnt multithreaded aware you will be severely crippled regarding CPU performance.

So I laugh at any OpenGL groopie saying their beloved API has really low CPU overhead as it matters when it cant scale past 1 thread anyway.

 

[bystander36]

I think your reading comprehension skills are at fault here. Did I ever said they are the same? Hint: the correct answer is not "yes"

I just said that multithreading is KEY into making a low CPU overhead API. No matter how thin is your driver or how low level can your API be, if it isnt multithreaded aware you will be severely crippled regarding CPU performance.

So I laugh at any OpenGL groopie saying their beloved API has really low CPU overhead as it matters when it cant scale past 1 thread anyway.

You keep saying that multithreading is key to making a low CPU overhead API, when multithreading has nothing to do with low overhead.

Multithreading allows you to get more out of a CPU, but it has nothing lowering overhead. It allows you to split the overhead up across multiple cores, but that does not lower the overhead. In fact, it increases the overhead, as there is overhead needed to control those threads.

I understand that multithreading helps remove the CPU bottleneck, but you are incorrectly using the term low overhead.

 

[Hitman928]

You keep saying that multithreading is key to making a low CPU overhead API, when multithreading has nothing to do with low overhead.

Multithreading allows you to get more out of a CPU, but it has nothing lowering overhead. It allows you to split the overhead up across multiple cores, but that does not lower the overhead. In fact, it increases the overhead, as there is overhead needed to control those threads.

I understand that multithreading helps remove the CPU bottleneck, but you are incorrectly using the term low overhead.

I was confused at first too, but I think what he means is that multithreading is key to making a low overhead API worth using.

 

[bystander36]

I was confused at first too, but I think what he means is that multithreading is key to making a low overhead API worth using.

Yeah, I believe that is what he is trying to say.

I think both are worth using, even on their own, but I do believe that at some point, you won't be able to keep reducing overhead. That has a limit to how much it can help, where as multithreading has endless potential, as CPU makers can keep adding cores, like GPU's have.

 

[PPB]

I was confused at first too, but I think what he means is that multithreading is key to making a low overhead API worth using.

Does anyone make software NOT to be used?

Tought that was already set in stone. Of what use is to make a single threaded low overhead api in the multicore era? API' cpu overhead isnt even a quantificable metric by itself, its dependant on a lot of properly defined factors, thread scaling being one if not the most important of them.

 

[Hitman928]

Does anyone make software NOT to be used?

Tought that was already set in stone. Of what use is to make a single threaded low overhead api in the multicore era?

I agree with you here, I think just it's important in a conversation that you really know where the other person is coming from; the point they're trying to make. If you can't start there, then it's pointless to try and have a conversation in the first place. Your first post left it a little unclear as to your point, I tried to clarify, that's all.

 

[Jodell88]

http://www.planet3dnow.de/cms/5720-apu13-andersson-will-mantle-fuer-alles-und-jeden/

It won't come to linux? If it came to linux Mantle would have a HUGE advantage over direct x. Looks to me like AMD sure knows that.

We'll see.



Agreed. Seems like AMD would be really dumb to tie themselves strictly to an OS that was owned/controlled by the company who writes the competing API.

http://www.phoronix.com/scan.php?page=news_item&px=MTY2NDA

 

[bystander36]

Does anyone make software NOT to be used?

Tought that was already set in stone. Of what use is to make a single threaded low overhead api in the multicore era? API' cpu overhead isnt even a quantificable metric by itself, its dependant on a lot of properly defined factors, thread scaling being one if not the most important of them.

Are we in a multithreaded era yet? There are only a handful of games that use multiple threads for the draw calls. There are a ton of 2 core PC users out there now that would benefit from low overhead more than multithreading the draw calls. Perhaps we are entering that era, or at least, starting to see the possibilities.

Now, before you keep arguing, let's talk about what overhead is. You are still misusing this term. Overhead is all extra stuff that is needed to make something work. It includes a lot of extra calls in order to make sure it works for a variety of systems, it can include a lot of checks to make sure the code doesn't try something it shouldn't. It is just the extra code used to run something.

Low overhead, or lower overhead means it reduces those extra calls, checks and balances in order to improve performance.

MULTITHREADING DOES NOT REDUCE OVERHEAD. Multithreading INCREASES overhead. It adds to the work load. It increases the calls. It does not reduce overhead. Multithreading spreads out the overhead to multiple cores to allow parallelism. While the overhead is increased, load balancing reduces overall time and increases performance.

Now please stop calling multithreading a method of reducing overhead. It does no such thing.

 

[DarkKnightDude]

They probably haven't announced it yet. If it supports AMD Linux, but not SteamOS?

 

[Gloomy]

They probably haven't announced it yet. If it supports AMD Linux, but not SteamOS?

Graham Sellers is AMD's OpenGL driver guy. What they're saying is he's going to be optimizing for the game on Linux. Not that the game will only run on AMD!

 

[bystander36]

I thought they were saying that it will not run on SteamOS, but it will run on AMD Linux. I thought SteamOS was a Linux distro. I wonder how many changes were made in SteamOS that makes it not work with normal Linux drivers.

 

[Jodell88]

I thought they were saying that it will not run on SteamOS, but it will run on AMD Linux. I thought SteamOS was a Linux distro. I wonder how many changes were made in SteamOS that makes it not work with normal Linux drivers.

By AMD Linux, they just mean their driver.

 

[Rakehellion]

I imagine the next Civ will be CPU bottlenecked on most systems. Even with only a 7850, my framerate scales linearly with clockspeed up to 4.8GHz in Civ5.

Civilization is a turn-based game, so it's pretty hard to make it CPU limited.

 

[VulgarDisplay]

The fact that they have apparently done a 180 on mantle coming to Linux would to me further insinuate what @repi hinted at about directx 12 being mantle. That would give them a pretty good reason to tie it down to windows.

 

[zlatan]

zlantan, can you expand on the predictable performance comment?

Well I have several issues about how D3D and the driver use the hardware. One of my main problem is the real time shader compilation is out of my control. I don't know when will happen and how much time will it take. I can't optimize directly for this scenario, and the performance is hardly depends on the driver. For example if I somehow make the code good enough and it didn't microstutter in my tests, than maybe a new driver will broke it and I have to patch the original code. This is so embarrassing for me and the industry because my customers want fluid gameplay, and I can't guarantee that. This is certainly not the way how real time shader compilation should work. Mantle will help here a lot, because with this API I can save complete pipelines with pre-compiled shaders. I just load them and you will have fluid gameplay with all drivers.

My second problem is how to deal with data hazards. This is one of the biggest problem in D3D, because you need to create resources but something have to deal with them. The driver must track all the writes and reads, because the write operations need to be completed before a shader read the actual resource. Now avoiding race conditions and hazards are controlled by the driver and this is bad, because I don't see what's going on under the hood. I just get the bad performance and I really don't know why. At this point I have to understand how the hardware is working which is kinda weird, because Nvidia don't document this, so I must use Intel and AMD GPU, than I somehow need to figure out what optimization should I use for Nvidia. Many times I just do some minor tweaks in the code, but it takes so much time to get better performance, because the driver don't let me see what's the problem.
This is what predictable performance means. Now I write a code, and maybe it has good performance, but maybe not. And if not I don't see where should I optimize. In Mantle the resource tracking is done by the application. Yes I have to write my own code for it, but I will see how it works. If the performance is weak I see where is the problem, and I patch it before the day ends.

The multi-threading model is still a problem in D3D. The API and the driver is the primary reason why we can't use efficient threading on PC. The kernel driver has hidden server threads and these are conflicts with the app threads. The best thing I can do is to limit the number of app threads, so the driver has two or three unused CPU cores, where it can do it's work. Deferred context just make this worse, because the driver use more aggressive threading, so you need to free up more CPU cores, likely four. But most PCs don't have more that four logical CPU cores, so if I free up these for the driver I don't have resource for the application.
I actually do manual threading with immediate context, which is not good, but I don't have better idea how to solve this puzzle in D3D. I think deferred context is a total failure. The command buffers can't be re-used, and many times this solution is slower than immediate context.
Mantle has a much more elegant multi-threading model. I have very good control over the hardware, there are no hidden driver threads, so I can use all the resources, all the cores, nothing will conflict with the app logic. This is how an API should work.

And how do you feel about DirectX 12, which will supposedly have many of the "direct metal" traits that Mantle was developed for.

I actually don't saw D3D12. My friend saw it and he said it's very similar to Mantle, so the difference between these APIs are negligible. Personally, I will definitely support D3D12 when it launches.

 

[itsmydamnation]

Are we in a multithreaded era yet? There are only a handful of games that use multiple threads for the draw calls.

thats because DX11 draw call threading doesn't buy you a return worth the investment.....

 

[Yuriman]

Civilization is a turn-based game, so it's pretty hard to make it CPU limited.

Have you even played Civ5?

It came out in 2010, and I have it installed on a Core2Quad, a Haswell i3 and an Ivy Bridge i5, all with the same video card. Late game on a large map, I have seen the Core2Quad get as low as 15fps sustained framerates just panning around the map. It's a slideshow. Hitting "next turn" can take upwards of 15-20 seconds. The i3 in those places delivers closer to 25fps but only with slightly better turn times. An overclocked i5 (~4.6GHz) in the same spot will be around 30fps when panning the map, and turn calculations generally take no more than 5 to 10 seconds.

I don't know what's going on under the hood in Civ, but I accept that the time needed to calculate a turn probably won't be improved by Mantle. Framerates almost certainly will. With the game maxed out (Civ5), a lowly 7850 has no problems delivering smooth framerates so long as you have enough CPU behind it. No amount of GPU will get you smooth framerates without a monstrous CPU.

Don't mistake a turn based game for an un-moving image.

 

[Silverforce11]

People underestimate the amount of objects and animations on-screen even in turn based strategy games. Classic examples: Rome 2 Total War, Shogun 2, Fallen Enchantress. All those pretty things on the world map punishes CPUs.

Any free CPU cycles due Mantle, would result in the CPU able to process AI faster, hence, quicker turns. Win win.

 

[PPB]

Are we in a multithreaded era yet?

MULTICORE ERA =/= Multithreaded era ---> Bother to read what I actually write, please.

Now, before you keep arguing, let's talk about what overhead is. You are still misusing this term. Overhead is all extra stuff that is needed to make something work. It includes a lot of extra calls in order to make sure it works for a variety of systems, it can include a lot of checks to make sure the code doesn't try something it shouldn't. It is just the extra code used to run something.

Instead of fumbling an entire paragraph trying to describe what overhead is, you should re-read what I wrote. I said overhead by itself is not quantificable, and that it depends on a whole world of factors, multithreading being one of the most significant. Your attempt at defining overhead is tangent to what I was actually discussing, at best, and wasnt even the point we are discussing.

MULTITHREADING DOES NOT REDUCE OVERHEAD. Multithreading INCREASES overhead. It adds to the work load. It increases the calls. It does not reduce overhead. Multithreading spreads out the overhead to multiple cores to allow parallelism. While the overhead is increased, load balancing reduces overall time and increases performance.

Now please stop calling multithreading a method of reducing overhead. It does no such thing.

The problem with your thinking is that you really cant process anything related to the multicore world we are living in, its like you are stuck to the pre C2D era or something.

Thus you think that overhead as a matter of the extra workload that a particular thread has to do to run the software being discussed, disregarding any other factor. If an API is low overhead but still mono-threaded, it means that you are ultimately binding yourself to the core's IPS (IPC*clockspeed), and will run in a bottleneck the moment that core is pegged to 100% load. This is just sad because you are not putting to use only 50% (in a dual core) to 12,5% (in a octa-core) of your total available performance for this task, when you actually could make a low overhead API with a really good multithreading (yeah, not talking about DX11 here) and putting all your available resources to use. In that case, even if enabling multithreading in your API increases your overhead by 20% (fumbling a number as this is what I mean when I was saying overhead by itself cant be quantificable), being able to spread the workload to the rest of the threads actually ends up lowering the CPU overhead of the API, as more total work is now needed to be done, but you have a whole lot more of CPU resources to deal with it.

People underestimate the amount of objects and animations on-screen even in turn based strategy games. Classic examples: Rome 2 Total War, Shogun 2, Fallen Enchantress. All those pretty things on the world map punishes CPUs.

Any free CPU cycles due Mantle, would result in the CPU able to process AI faster, hence, quicker turns. Win win.

I throw one example to this assesment: CoH (even tho this is a proper RTS) with its unique squadron system, where one unit doesnt traslate directly to a prefixed ammount of draw calls (you can have from 1 to 6 soldiers in the same squad, each one can have its unique uniforms, guns, skins, etc and if you dont instance/proxy those it will traslate to more draw calls ) can see a good deal of improvement from going the mantle road. Freeing up cycles for the AI pathing system, a better ballistic system, the probability-based damage model, etc is good for everyone. Heck, I would kill for a more optimized AoE II, no matter what CPU you run, it will run like crap after a 3 hour battle in that game (not even talking modded battles with 1k units per player here).

 

[bystander36]

@ PBB:
Let me make this simple, as it seems that a long post makes it less likely to be read entirely.

From the start, I agree about all the great things that multithreading does.

You do not know what "overhead" means. You do not know what "low overhead" means either.

Because of this lack of understanding, my posts have not made sense to you and you are arguing with me about things I agree with you about.

 

[f1sherman]

Don't mistake a turn based game for an un-moving image.

And why not?
OK how about lightly animated, almost static, highly predictable... with panning.

Am I missing something - what kind of terrific calculations goes on in the background to warrant this CPU hunger.

 

[NTMBK]

And why not?
OK how about lightly animated, almost static, highly predictable... with panning.

Am I missing something - what kind of terrific calculations goes on in the background to warrant this CPU hunger.

Errm, modelling the progression of human civilization?