[roytries]

I'm purely a hobbyist. But I was under the impression that D3D12 is so different compared to D3D11 that this would be a good time to consider both D3D12 and Vulkan. Is the choice for D3D12 standard because it 'sounds' familiar. Or is there more overlap with D3D11 than I was aware of?

[Jasper_]

D3D12 is very different from D3D11, but still has a lot in common. We started our port by reusing most of the same DXGI code and getting what we called our "sprites" rendering correctly (2D quads, used by the loading screen, and our debug UI). We were able to reuse a lot of code, including all of our existing HLSL shaders. None of that would work with Vulkan, at least without a lot more work (which we eventually did).

The parts that were D3D12-specific were definitely the parts that would overlap more with Vulkan: the work to switch to PSO (Pipeline State Objects), the addition of all the barriers all over the rendering code, the synchronization work, all of that work could be shared between D3D12 and Vulkan.

[joe91]

You do need a very different design to efficiently target D3D12 and Vulkan. You need to think in terms of pipelines, root signatures/descriptor layouts, tables of descriptors and resource transitions. But its quite easy to also target D3D11 in this way:

Pipeline state -> struct of the 3 or 4 state objects + a few values (this actually makes redundancy checking easier and can actually be a win :)

Root signature -> fixed pre allocation of binding slots (this can even be done statically with templates if your root signature is known statically)

Tables of descriptors -> arrays of handles

(edit: you obviously cannot do the kinds of bindless things with D3D11 that you can do with D3D12 and Vulkan. But its common to have both bindless and non-bindless code paths with D3D12 and Vulkan anyway)

Resource transitions -> nothing