4 ms·

D3D12 is nothing like mantle. Not even close. D3D12 is heavily derived from D3D11. D3D12's own documentation is even specified as 'behaves like D3D11 except for

D3D12 is nothing like mantle. Not even close. D3D12 is heavily derived from D3D11. D3D12's own documentation is even specified as 'behaves like D3D11 except for these bits'. If anything, Vulkan is a clone of Mantle because Vulkan is Mantle. It was donated to the Khronos Group by AMD and served as the foundation for Vulkan. If you have both API headers for Vulkan and Mantle side by side it's shocking how similar they are. Vulkan 1.0 is largely just Mantle with more API ceremony for tile-based mobile GPUs and NVidia's (at the time) far more restrictive binding model.

shmerl 4y ago
It was derived directly from Mantle, same as Vulkan. See the link above which literally records that historic fact. Same way Mantle was used for Vulkan by Khronos, MS used it for their NIH becasue they didn't want for collaborative effort to reduce their grip on the gaming market. Without AMD, MS would have never came up with DX12 on their own so fast. AMD expressed the interest in collaborative API quite early on and Mantle was presented for that very purpose. Khronos used that as intended, while MS hijacked that for their own market manipulation purposes in their usual MS only way.
- MindSpunk 4y ago
  The linked tweet only really shows that some of their documentation language was 'borrowed'. The actual API semantics are nothing like Mantle or Vulkan. The synchronization model is completely different, the queue system is completely different, the memory allocation model is completely different. The binding models are massively different. Maybe some of the core ideas behind Mantle were taken with explicit synchronization, and maybe they started from Mantle as a base but the end result is completely alien to what Mantle was. Microsoft could never justify using Vulkan over DirectX 'Next' to its developers. It would be a total deprecation of Direct3D. It would require all their developers to throw their entire renderer backend out and start fresh with 100% new tools. A lot of effort was put into making the transition to D3D12 from D3D11 easy, even to (IMO) the detriment of the API semantics. They even kept shaders inter compatible while adopting an enormously different binding model. D3D12 is also largely a much friendlier API to use. Vulkan is (was) verbose to the extreme in ways that really didn't matter to the majority of Direct3D users on desktop GPUs. Vulkan render passes are a nightmare to work with, and largely served no benefit to the desktop and console GPUs Direct3D is used for. Vulkan has evovled a lot since 1.0, relaxing lots of the excessive restrictions that were originally there. A lot of this stuff likely wouldn't have happened if it weren't for D3D12 putting pressure on Khronos to improve the developer experience. Vulkan is not the panacea people think it is, but it's getting better. And so is D3D12 by borrowing some of Vulkan's better ideas. To say D3D12 should have never existed is just 'M$ bad' dogma.
  - shmerl 4y ago
    Semantics drifted over time. The main input was still Mantle, no a bit of doubt about it. That documentation shows it was borrowed practically verbatim in the early form. Vulkan also didn't keep Mantle as is in every aspect when it used it. Point is, MS didn't need to build things from scratch. They used Mantle as the starting point, same way Khronos did. So the question one should be asking, why MS didn't collaborate while they very well knew the collaborative API is going to happen. No one stopped them from making that collaborative API more friendly or better. But MS being MS they rushed with NIH.
    - MindSpunk 4y ago
      I suppose it could be seen as NIH, but there are legitimate engineering benefits for Microsoft with its own API. It's important to remember that Direct3D used to be a completely separable component from Windows, and wasn't installed by default. Around the same time D3D12 and Vulkan were happening Windows also pulled D3D in as a core system component that will be universally available. If you're an engineer trying to pick "the" GPU API for Windows the only real argument that can be made for picking Vulkan, the open API, over the internal API Microsoft already had for ~15 years by that point is that it's the 'open source friendly' choice. How do you justify using someone else's API as a core Windows API over your own solution that you already had. There's no engineering or business justification really. It's similarly easy to construe Vulkan and Mantle as an attempt by AMD to take control of the GPU API space and specify an API particularly friendly to their hardware as the standard. They largely even succeeded considering what Vulkan became. Even D3D12's binding model is basically an exercise in how close we can get to directly exposing AMD's "anything goes" binding model while still allowing NVidia to function. It's very nice as a GPU vendor when your driver can be made closer to a no-op than your competitors. Too many people pile on D3D12 simply because of Microsoft, rather than fairly considering the context of what created it. Apple made the same decision too with Metal, but I rarely hear any complaints there.
      - shmerl 4y ago
        Engineering reasons just don't seem convincing when MS has DX only policy on Xbox and a long history of anti competitive behavior, especially in the gaming segment. If MS would have allowed using Vulkan on Xbox for instance, I would have been more willing to give them the benefit of a doubt. But as it stands, I see them pushing DX as having lock-in motives.

shmerl 4y ago

It was derived directly from Mantle, same as Vulkan. See the link above which literally records that historic fact. Same way Mantle was used for Vulkan by Khronos, MS used it for their NIH becasue they didn't want for collaborative effort to reduce their grip on the gaming market. Without AMD, MS would have never came up with DX12 on their own so fast. AMD expressed the interest in collaborative API quite early on and Mantle was presented for that very purpose. Khronos used that as intended, while MS hijacked that for their own market manipulation purposes in their usual MS only way.

MindSpunk 4y ago
The linked tweet only really shows that some of their documentation language was 'borrowed'. The actual API semantics are nothing like Mantle or Vulkan. The synchronization model is completely different, the queue system is completely different, the memory allocation model is completely different. The binding models are massively different. Maybe some of the core ideas behind Mantle were taken with explicit synchronization, and maybe they started from Mantle as a base but the end result is completely alien to what Mantle was. Microsoft could never justify using Vulkan over DirectX 'Next' to its developers. It would be a total deprecation of Direct3D. It would require all their developers to throw their entire renderer backend out and start fresh with 100% new tools. A lot of effort was put into making the transition to D3D12 from D3D11 easy, even to (IMO) the detriment of the API semantics. They even kept shaders inter compatible while adopting an enormously different binding model. D3D12 is also largely a much friendlier API to use. Vulkan is (was) verbose to the extreme in ways that really didn't matter to the majority of Direct3D users on desktop GPUs. Vulkan render passes are a nightmare to work with, and largely served no benefit to the desktop and console GPUs Direct3D is used for. Vulkan has evovled a lot since 1.0, relaxing lots of the excessive restrictions that were originally there. A lot of this stuff likely wouldn't have happened if it weren't for D3D12 putting pressure on Khronos to improve the developer experience. Vulkan is not the panacea people think it is, but it's getting better. And so is D3D12 by borrowing some of Vulkan's better ideas. To say D3D12 should have never existed is just 'M$ bad' dogma.
- shmerl 4y ago
  Semantics drifted over time. The main input was still Mantle, no a bit of doubt about it. That documentation shows it was borrowed practically verbatim in the early form. Vulkan also didn't keep Mantle as is in every aspect when it used it. Point is, MS didn't need to build things from scratch. They used Mantle as the starting point, same way Khronos did. So the question one should be asking, why MS didn't collaborate while they very well knew the collaborative API is going to happen. No one stopped them from making that collaborative API more friendly or better. But MS being MS they rushed with NIH.
  - MindSpunk 4y ago
    I suppose it could be seen as NIH, but there are legitimate engineering benefits for Microsoft with its own API. It's important to remember that Direct3D used to be a completely separable component from Windows, and wasn't installed by default. Around the same time D3D12 and Vulkan were happening Windows also pulled D3D in as a core system component that will be universally available. If you're an engineer trying to pick "the" GPU API for Windows the only real argument that can be made for picking Vulkan, the open API, over the internal API Microsoft already had for ~15 years by that point is that it's the 'open source friendly' choice. How do you justify using someone else's API as a core Windows API over your own solution that you already had. There's no engineering or business justification really. It's similarly easy to construe Vulkan and Mantle as an attempt by AMD to take control of the GPU API space and specify an API particularly friendly to their hardware as the standard. They largely even succeeded considering what Vulkan became. Even D3D12's binding model is basically an exercise in how close we can get to directly exposing AMD's "anything goes" binding model while still allowing NVidia to function. It's very nice as a GPU vendor when your driver can be made closer to a no-op than your competitors. Too many people pile on D3D12 simply because of Microsoft, rather than fairly considering the context of what created it. Apple made the same decision too with Metal, but I rarely hear any complaints there.
    - shmerl 4y ago
      Engineering reasons just don't seem convincing when MS has DX only policy on Xbox and a long history of anti competitive behavior, especially in the gaming segment. If MS would have allowed using Vulkan on Xbox for instance, I would have been more willing to give them the benefit of a doubt. But as it stands, I see them pushing DX as having lock-in motives.