I have been building a home grown engine for a few years now just as a hobby using dx9, so not working on it full time. So my question is, eventually I will need to update to directx11, and was just curious if someone with experience could enlighten me how difficult this could be. Really just changing how you use the d3ddevice right? I am already using a programmable pipeline, so that wont be an issue, but are there any other big challenges involved? Thanks.
1
Updating engine from dx9 to dx11
Started by Slig Commando, Sep 29 2012 09:42 PM
5 replies to this topic
Sponsor:
#2 Members - Reputation: 312
Posted 29 September 2012 - 10:26 PM
Make sure all your effect files designate row_major - Matrices (float4x4) are row major by default in DX9, and column major (matrix) in DX10 and DX11.
More generally speaking, my own game engine seems to be working fine just wrapping DX9, D10 and DX11 in genericized classes. Ideally, only the smallest possible part of the foundation of your engine should even know it's using DirectX, or which version.
If you've built it along good "separation of concerns" lines, you should be able to swap out that small subset. You could even put it in a DLL - DX9API.dll, DX10API.dll, DX11API.dll. Then, when/if you get your hands on DX12, or OpenGL, or whatever, you can swap in a DX12API.dll, OpenGLAPI.dll (not familiar with OpenGL version numbers) or, I dunno, AsYetUninventedConsoleAPI.dll.
In short, there's no reason even so much as your Mesh class/struct should have a clue what you're using - Leave that to your VertexBuffer and IndexBuffer classes.
More generally speaking, my own game engine seems to be working fine just wrapping DX9, D10 and DX11 in genericized classes. Ideally, only the smallest possible part of the foundation of your engine should even know it's using DirectX, or which version.
If you've built it along good "separation of concerns" lines, you should be able to swap out that small subset. You could even put it in a DLL - DX9API.dll, DX10API.dll, DX11API.dll. Then, when/if you get your hands on DX12, or OpenGL, or whatever, you can swap in a DX12API.dll, OpenGLAPI.dll (not familiar with OpenGL version numbers) or, I dunno, AsYetUninventedConsoleAPI.dll.
In short, there's no reason even so much as your Mesh class/struct should have a clue what you're using - Leave that to your VertexBuffer and IndexBuffer classes.
Now open: MouseProduced Games
#3 Moderators - Reputation: 14301
Posted 30 September 2012 - 03:06 AM
Two of the biggest differences to me are -
* DX9 vertex declarations are forgiving in that they can be slightly incorrect and still work. DX11 input layouts on the other hand need to exactly match your vertex shader input structure. This means that if the same mesh is drawn using 2 shaders, you may need 2 input layouts.
* DX11 render states are immutable objects. E.g. You can't just set "depth test = less" at any time, instead you've got to create a complete depth-stencil-state object ahead of time. If porting a DX9 engine, you might need to create a bunch of large tables/maps of state objects in advance.
* DX9 vertex declarations are forgiving in that they can be slightly incorrect and still work. DX11 input layouts on the other hand need to exactly match your vertex shader input structure. This means that if the same mesh is drawn using 2 shaders, you may need 2 input layouts.
* DX11 render states are immutable objects. E.g. You can't just set "depth test = less" at any time, instead you've got to create a complete depth-stencil-state object ahead of time. If porting a DX9 engine, you might need to create a bunch of large tables/maps of state objects in advance.
I don't know about D3DX math, but the HLSL compiler hasn't changed in that column_major is the default float4x4 layout in DX9 too.Make sure all your effect files designate row_major - Matrices (float4x4) are row major by default in DX9, and column major (matrix) in DX10 and DX11.
#5 Members - Reputation: 4032
Posted 30 September 2012 - 06:57 AM
A third major difference I'd highlight is use of constant buffers instead of free-standing constants in HLSL code. Depending how you've currently got things set up that may result in a good deal of re-thinking, re-organizing and re-writing.
There are also many smaller, more subtle differences throughout the two versions, such as the differences between Lock and Map, and these can sometimes trip you up.
Around the release of D3D10 the major GPU vendors published sets of slides outlining advice and trouble-spots to look out for, and these are still quite relevant to D3D11 and worth reading. Here's a good overview: http://developer.download.nvidia.com/presentations/2008/GDC/GDC08-D3DDay-Performance.pdf
There are also many smaller, more subtle differences throughout the two versions, such as the differences between Lock and Map, and these can sometimes trip you up.
Around the release of D3D10 the major GPU vendors published sets of slides outlining advice and trouble-spots to look out for, and these are still quite relevant to D3D11 and worth reading. Here's a good overview: http://developer.download.nvidia.com/presentations/2008/GDC/GDC08-D3DDay-Performance.pdf
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#6 Moderators - Reputation: 5644
Posted 30 September 2012 - 10:09 AM
The initial port probably won't be too hard for you. It's not too hard to spend a week or two and get a DX9 renderer working on DX11. What's harder is actually making it run fast (or faster), and integrating the new functionality that DX11 offers you. Constant buffers are usually the biggest performance problem for a quick and dirty port, since using them to emulate DX9 constant registers can actually be slower than doing the same thing in DX9. Past that you may need a lot of re-writing for things like handling structured buffers instead of just textures everywhere, having texturs/buffers bound to all shader stages, changing shaders to use integer ops or more robust branching/indexing, and so on.
Edited by MJP, 30 September 2012 - 10:09 AM.
