5 ms·

This is a very inaccurate summary of the space. There aren't that many studios doing Vulkan ports, unless you want to target Linux, but even Valve prefers Proto

This is a very inaccurate summary of the space. There aren't that many studios doing Vulkan ports, unless you want to target Linux, but even Valve prefers Proton and are telling people not to port. Or Android/Stadia, but nobody gives a shit about that to do that. The big engines have support for both Vulkan and D3D12, and use the D3D12 backend on Windows. Studios are porting to D3D12, by comparison, somewhat because of Xbox, but also because it's a somewhat standard upgrade from D3D11. The developer experience of the D3D12 debug layer is much better than Vulkan. Disclaimer: I lead the Vulkan and D3D12 ports of the engine at the last game studio I worked at.

roytries 5y ago
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?
- joe91 5y ago
  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
- Jasper_ 5y ago
  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.
zibzab 5y ago
Is this an official Steam recommendation? BTW, it hurts me to see GP being flagged. Please discuss your arguments instead of flagging comments you don't agree with.
- mikestew 5y ago
  Please discuss your arguments instead of flagging... When a comment starts with "walled garden", there usually isn't anything to discuss. Just like the assumption-filled title of this post, the commenter has already established their position with a tiresome, and probably not even accurate, assessment of the situation. I don't know if that warrants flagging, but it sure doesn't warrant much discussion.
  - zibzab 5y ago
    When did "walled garden" become a taboo word? It is not an impossibility, we simply don't know. Just flagging comments _you_ find tiresome is not good for the discussion.
  - smoldesu 5y ago
    If Apple offered Metal alongside third-party APIs like Vulkan, I wouldn't be so quick to draw conclusions. However, they made the move to muscle out open graphics APIs from their desktop OS, and the only assumption I'm left to make is that they're directing people onto their own proprietary API in an attempt to lock down their developers and users. Again, if Metal were available on other platforms, or had actual competitors in the space, I wouldn't be so harsh. Until that is the case, it's the same as Apple's App Store: an undeniable walled garden. You can disagree with me, you can cite dissenting opinions if you want, but it's no different than the rest of Apple's product strategy.
- Koiwai 5y ago
  Let's just say it tells how many apple fanboys are here.
Koiwai 5y ago
> but even Valve prefers Proton and are telling people not to port. Citations? https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Native-1.9.2a https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Nat...

roytries 5y ago

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?

joe91 5y ago
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
Jasper_ 5y ago
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.

zibzab 5y ago

Is this an official Steam recommendation? BTW, it hurts me to see GP being flagged. Please discuss your arguments instead of flagging comments you don't agree with.

mikestew 5y ago
Please discuss your arguments instead of flagging... When a comment starts with "walled garden", there usually isn't anything to discuss. Just like the assumption-filled title of this post, the commenter has already established their position with a tiresome, and probably not even accurate, assessment of the situation. I don't know if that warrants flagging, but it sure doesn't warrant much discussion.
- zibzab 5y ago
  When did "walled garden" become a taboo word? It is not an impossibility, we simply don't know. Just flagging comments _you_ find tiresome is not good for the discussion.
- smoldesu 5y ago
  If Apple offered Metal alongside third-party APIs like Vulkan, I wouldn't be so quick to draw conclusions. However, they made the move to muscle out open graphics APIs from their desktop OS, and the only assumption I'm left to make is that they're directing people onto their own proprietary API in an attempt to lock down their developers and users. Again, if Metal were available on other platforms, or had actual competitors in the space, I wouldn't be so harsh. Until that is the case, it's the same as Apple's App Store: an undeniable walled garden. You can disagree with me, you can cite dissenting opinions if you want, but it's no different than the rest of Apple's product strategy.
Koiwai 5y ago
Let's just say it tells how many apple fanboys are here.

Koiwai 5y ago

> but even Valve prefers Proton and are telling people not to port. Citations? https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Native-1.9.2a https://www.phoronix.com/scan.php?page=news_item&px=DXVK-Nat...