Performance improvements from Dx9 to Dx10/11

Started by
4 comments, last by そら 10 years, 11 months ago

Hi,

I was in an interview last week, and one of the questions I was asked was "What peformance improvements were made into DirectX when moving from Dx9 to Dx10/11?"...

I have worked with Dx9 and Dx11, but this question totally freaked me out, because I don't know (maybe I'm still very young on this); however, I remember to have read that it reduced "micro-batching" (although I don't know how it does so or why).

So, I thought that it would be a good idea to ask you guys and learn a little bit about it.... so, basically that's the question, what improvements were made in the API / Architecture when changing from Dx9 to Dx10/11 that helped to improve the performance?

Thanks!

"lots of shoulddas, coulddas, woulddas in the air, thinking about things they shouldda couldda wouldda donne, however all those shoulddas coulddas woulddas ran away when they saw the little did to come"
Advertisement

That's a pretty weird question to ask at an interview, IMO. Off the top of my head...

  • Changed the driver model so that the driver has a user-mode DLL in between the D3D runtime DLL and the kernel-mode driver DLL
  • Changed API's so that you can set multiple textures/buffers/render targets in a single call instead of one at a time
  • Removed a lot of old cruft that was being emulated on GPU's, or not supported at all
  • Introduced constant buffers, which can be much faster to update compared to the old constant registers used in D3D9
  • Moved device states into immutable state objects. This results in less API calls, and allows validation to be done once during initialization.
  • Input layouts allow the driver to create fetch shaders earlier, and re-use them more efficiently
  • D3D11 added multithreaded rendering, which can potentially allow you to improve total performance if you have a few cores to spare.

These are all of the changes I can think of that relate to CPU performance of the API itself, as opposed to performance gains you might get on the GPU due to having access to more functionality.

Thanks MJP!

uhmmm... yeah, makes sense what you say!... very interesting...

like what old cruft do you refer to?...

by saying: "having access to more functionality" you refer to all the spec's provided on the upper feature levels, right?

Thanks again!

"lots of shoulddas, coulddas, woulddas in the air, thinking about things they shouldda couldda wouldda donne, however all those shoulddas coulddas woulddas ran away when they saw the little did to come"

"Old cruft" would mostly refer to the fixed-function pipeline and everything that went with it.

As for "more functionality", yes this would mostly be the things enabled by the higher feature levels. So things like new shader types, new resource types (texture arrays, structured buffers, append buffers), access to MSAA sample data, new texture sampling functions (Gather, SampleCmp), integer instructions, new render target and compressed texture formats, etc.

MJP's hit the nail on the head already wink.png

Another "more functionality" thing is that compute shaders offer new ways of structuring your computation. Many image processing algorithms, like summed area tables are much easier to implement in a compute shader than a fragment shader. With unordered-access-views, shaders can now perform arbitrary reads and writes to memory, which allows many more types of algorithms to be implemented on the GPU.

cool!...

I think that has clarified my mind now...

thank you both!... =)

"lots of shoulddas, coulddas, woulddas in the air, thinking about things they shouldda couldda wouldda donne, however all those shoulddas coulddas woulddas ran away when they saw the little did to come"

This topic is closed to new replies.

Advertisement