Civ 5 interview. First 'native DX11 game'

[Genx87]

Wait a minute, something I don't understand here. What are they referring to when they speak of multi-threaded graphics drivers? You're telling me current drivers from Nvidia and AMD, both of which are drivers for highly parallel graphics architectures, do not allow modern graphics cards to process multiple threads per clock?

I was a bit confused on this as well. I swear Nvidia and AMD made their drivers multicore aware years ago?

 

[smithkt]

I was a bit confused on this as well. I swear Nvidia and AMD made their drivers multicore aware years ago?

Sylvanas linked to an AT article which talks about this a few posts up. Here it is again.

http://www.anandtech.com/show/2716/4

 

[T2k]

I just skimmed through it but why would you call it native DX11 when in fact it is built on DX9 with added DX10/11 features?

Because it sounds good.

Any game developed in DX11 is 'native' and vica versa, any DX11 supports running on DX10 and DX9-level hardware via 10level9: http://msdn.microsoft.com/en-us/library/bb694529%28VS.85%29.aspx

 

[toyota]

Because it sounds good.

Any game developed in DX11 is 'native' and vica versa, any DX11 supports running on DX10 and DX9-level hardware via 10level9: http://msdn.microsoft.com/en-us/library/bb694529%28VS.85%29.aspx

well I guess I am thinking about native DX10 games like Shattered Horizon and Just Cause 2 that were DX10 from ground up and they could not be run in DX9. I assumed that would apply to native DX11 too.

 

[VirtualLarry]

Will Civ V work on onboard ATI graphics? Or does it require DX11? Thinking of AMD 760G/780G/785G-level graphics. (Which Civ 4 runs on just fine, IMHO.)

 

[toyota]

Will Civ V work on onboard ATI graphics? Or does it require DX11? Thinking of AMD 760G/780G/785G-level graphics. (Which Civ 4 runs on just fine, IMHO.)

of course it doesn't require DX11 and that is mentioned in the link and throughout this thread. I have no idea if it can run on sufficiently on those level of graphics though.

 

[Juncar]

There are two options for running Civ5, either DX9 or DX10 & DX11 (single option).

 

[bryanW1995]

PcgamesHardware always have good tech interviews.

more

Looks like they've employed all levels of the benefits of DX11- Tesselation, DirectCompute and Muti-threaded engine. Speaking of threading:



So neither Nvidia nor ATI have released multi-threaded DX11 drivers yet. It will be interesting to see what benefits this brings when it arrives, lets hope we see more studios like Firaxis supporting DX11 and making use of our hardware.

Also : (on Tesselation)


Finally Tesselation that does not tank performance but actually improves it as was intended.

I look forward to benchmarks in future- most notable would be comparing the differences in performance between 58xx / 6xxx and Fermi given the superior Tesselation capability of the latter. I wouldn't be surprised either if Nvidia is first to market with 'threaded DX11 drivers' as they usually are with these things though I'd like to be surprised.

I tried civ5 out on dx9 mode the other day just to see what wout happen. first of all it reset all my quality settings down to low/med. I game at 1680x1050, and once I reset everything to high and 4xAA (where I run it in 11 mode) the graphics absolutely slowed the game to a crawl. I exited and restarted in dx 11 mode and it was back to running smoothly. HUGE difference.

Hopefully you're right about nvidia having multithreaded drivers out first

 

[bryanW1995]

Will Civ V work on onboard ATI graphics? Or does it require DX11? Thinking of AMD 760G/780G/785G-level graphics. (Which Civ 4 runs on just fine, IMHO.)

I have a laptop at home with hd 3200 onboard. I play civ 4 on it frequently at mid/low settings. I'll dump steam/civ 5 on it tonight and let you know. Don't hold your breath, though, even my i7 920 with gtx 460 was pretty gimpy in dx 9 mode...

 

[Dekasa]

The multi-threading probably refers to that DX11 can use a multi-threaded rendering thread. In DX10 and under the rendering all had to be on a single thread, and this thread was typically very intensive. Multi-threading it should bring significant gain.

 

[Dankk]

Will Civ V work on onboard ATI graphics? Or does it require DX11? Thinking of AMD 760G/780G/785G-level graphics. (Which Civ 4 runs on just fine, IMHO.)

You can choose to run it in DirectX 9. My laptop's 785G (Radeon HD 4200) can run Civ 4 without a hitch, I would imagine that Civ 5 should run decently in DirectX 9 mode on low-medium settings as well. Though I haven't actually tried it yet.

 

[dunno99]

To understand what multi-threaded DX drivers are, you have to understand what the underlying implementation is. So let's take a look at a modern game engine, DX implementation, and the underlying hardware.

To start, the underlying hardware is a per-context command-serial hardware. As in, for each context, it is serial in how it process the incoming commands. This command stream is what we normally refer to as the "command buffer" or "push buffer". The commands in these buffers are the raw binary machine code for the graphics card to consume. Now, the question is, how are these command codes generated?

This is where the driver comes in. The driver basically boils down to an implementation of the OpenGL/Direct3D interface that translates incoming function calls (with data) into hardware-specific machine code. Of course, there are a lot of restrictions on what the OpenGL/Direct3D states are when specific commands are called, and also what the restrictions are with the underlying hardware. In essence, you can think of the driver as a compiler.

On the other end of the spectrum is the 3D engine. The 3D engine calls the OpenGL/Direct3D interface, which is essentially an abstraction of a virtual device with a single interface. The 3D engine calls the functions exposed by OGL/D3D and assumes that the underlying device conforms to the specs of OGL/D3D. In theory, this means for any hardware that supports the interface, the 3D engine code doesn't have to worry about the actual implementation of the hardware, since the drivers will translate their OGL/D3D commands into the hardware-specific commands.

So, where does this all lead? Well, when the 3D engine has to call into the drivers, the driver takes up some processing resources from the engine. If the engine is really fast, it might call enough times into the driver such that the driver becomes the bottleneck instead of the engine itself. Obviously, then one would think that "hey, I got multiple cores on my machine, I should be able to spread some of the driver load onto the other cores, right?"

Well, yes and no. The problem is that the command stream for the context is presumed to be serial (remember what I mentioned earlier?). So if you have a command stream with multiple things writing to it at the same time, the order isn't quite so guaranteed, right?

But then, some half-assed programmer will ask "why not just put locks on it then?". Well, the problem with that is:
1) the driver will be locked all over the place,
2) locking across multiple cores is pretty expensive, since that involves going back to L2 or potentially L3 cache...and for this case, since we're bound by driver calls already, that means not being able to acquire locks is going to be a huge issue,
3) introduces huge problems with deadlocks and whatnot.
So yeah, it's basically a no-go.

Luckily, graphics tend to be serial (in terms of the incoming command streams). That and we know ahead of time what we need to do anyway -- it's just the process of doing it takes so long. Well, great! The DX11 spec team basically exploits this fact and says, "Well, let's do this. Since you're generating a command buffer, why not break this command buffer up into multiple segments. There will be one main buffer, which is the one that your main thread keeps, and where all synchronization happens. We'll have many other (usually) smaller segments that the main buffer can jump to and back from. Then we'll let other threads fill up these smaller segments, and basically paste/link into the main buffer when and where these smaller segments will get executed."

So, this is awesome. No locks, no synchronization pain. Multi-threaded up to as many sub-jobs as you can get (it can be a LOT). Perfect!

Oh wait, one small problem. The ATi/nVidia drivers don't quite support it yet. Either it still just goes back to that one main thread, or something. I don't know what the deal is.

 

[VirtualLarry]

EXCELLENT post, dunno99.

 

[bryanW1995]

NV has in the past been very good with their drivers, hopefully soon they'll have a beta driver for this. Hopefully this game is big enough that they'll spend some time on it.

 

[Dark_Archonis]

Sylvanas linked to an AT article which talks about this a few posts up. Here it is again.

http://www.anandtech.com/show/2716/4

Thanks for the link, that explains a lot. I had no idea DirectX was so far behind graphics architectures. Amazing that only now with DirectX 11 can programmers get meaningful multi-threading optimizations from the API.

This makes upgrading to DirectX 11 much more useful than simply for the latest visual features.

 

[tviceman]

NV has in the past been very good with their drivers, hopefully soon they'll have a beta driver for this. Hopefully this game is big enough that they'll spend some time on it.

Since it's release, it's been the most played game on steam at some point in every day. A game like this typically has longer legs with sales vs. the industry norm, and it's peaked with 75,000 concurrent players so yeah I'd say it's pretty big.

But anyways, I'm getting really good performance on my gtx465. If anything my processor is holding the game's performance my GPU. Also, longer I stay in game the more performance will degrade. Quitting to desktop and then going back in to where I left off fixes it, so that's probably a memory leak.

 

[bryanW1995]

ok, just played on my laptop.

it's a ql 64 with hd 3200 graphics and 3gb ram. ran it on dx 10/11 codepath, it ran ok for a couple minutes then crashed. every single setting was defaulted to minimum or low, with one or two just turned off completely.

 

[Sylvanas]

Excellent post dunno99, bookmarked for later.

Techspot have put together a good article that encompasses all recent GPUs. I'll update my post later but footnotes seem to be:

Tesselation incurs a very small hit.
GTX460 outperforming a 5870.
GTX480 taking a significant lead in 2560x1600.
Doesn't scale above 4 threads.
i7 leading and core frequency makes a big difference.

 

[Skurge]

Excellent post dunno99, bookmarked for later.

Techspot have put together a good article that encompasses all recent GPUs. I'll update my post later but footnotes seem to be:

Tesselation incurs a very small hit.
GTX460 outperforming a 5870.
GTX480 taking a significant lead in 2560x1600.
Doesn't scale above 4 threads.
i7 leading and core frequency makes a big difference.

That is poor performance from the 5000 series cards, just reaffirms their poor DX11 performance.

It could be drivers also as I would not like to be GT200 series owner. The 285 is horribly slow and just barely playable on medium.

 

[betasub]

Thanks, Sylvanas. I like my reviews fresh

 

[tviceman]

Wow, the gtx460 beats the hd5870, and the gap between the gtx480 and hd5870 at 1920x1080 is ridiculous!

 

[RussianSensation]

Tesselation incurs a very small hit.

Tessellation = massive performance hit for previous gen architectures.

They set Tessellation to low, not that the performance hit was low.

By using low Tessellation, the GeForce GTX 285 rendered an extra 93%, GeForce GTX 260 received a 100% performance bump. The Radeon HD 4850 was also 82% faster and the Radeon HD 4890 achieved 58% frames per second.

Most shocking is both how poorly NV's GT200 architecture performs at with tessellation and how much NV has improved its tessellation with Fermi:

HD4890 = 24 :thumbsup: (What would Rollo say??)
GTX285 = 15
GTX275 = 13
GTX260 = 12

GTX460 outperforming a 5870.

Looks like another DX11 game win for NV. Looks like NV's claims of having a 60% faster DX11 implementation may not be so far-fetched. HD6000 should fix DX11 performance.

Doesn't scale above 4 threads.

Q6600 is almost 2x slower than Core i5 750 (same as SC2). i3 540 is 20% faster than E8500 despite the higher clock speed of the latter, while i5 750 is still 24% faster than the i3 540. Looks like Civ5 loves everything: modern architecture, cache, clock speed, and a quad-core. So much for claims that C2D/Q is almost as fast i5/i7s in games. Granted, this type of game is an extreme example of CPU dependence.

 

[yepp]

http://www.techspot.com/review/320-civilization-v-performance/

Civ 5 loves the GTX 400 cards, GTX 460 out performs HD 5870.

A big surprise is the poor showing of Nvidia's last gen cards, GTX 285 slower than HD 4850 and HD 5670! Driver problem? DX10 slower than DX10.1, DX11?

Another note, with tessellation disabled or medium image quality the HD 4890 pips the HD 5850.

Edit: just notice this has previously been posted in another thread, mods pls lock.

Merging this thread with the other Civ5 thread.

Moderator Idontcare

 

[iGas]

Thanks for the post.

It is exactly what I was waiting for. I'm going to upgrade to the GTX 460, and Phenom 970 BE for Civ 5.

 

[Attic]

Wow. Damn, have my 5770 rig upstairs and my 460 in my HTPC, but Civ5 doesn't play well on the HTPC because of the large amount of text.