5 ms·

You are aware of the history of DX right? Their SDK is old and really good. Just because Vulkan exist doesn't mean DX is invalid. Good to have more than one

You are aware of the history of DX right? Their SDK is old and really good. Just because Vulkan exist doesn't mean DX is invalid. Good to have more than one thing. Innovation and stuff

kevingadd 4y ago
Arguably without the OpenGL vs D3D and now Vulkan vs D3D back and forths, along with experimental APIs like MANTLE, we definitely wouldn't have a lot of the robust tech we have access to today. OpenGL's freeform experimentation and evolution with extensions let people test things out in production environments to figure out what worked, while D3D's stable feature set meant that games and productivity software could - if it made sense for the developer - choose to ship a more limited feature set that worked everywhere, all of the time. D3D also has consistently offered great debugging tools and a robust reference rasterizer, things you simply can't get in an OpenGL environment. As a game developer it's invaluable to be able to swap over to a Direct3D backend for debugging even if you end up using OpenGL as your default. (These days, Vulkan has first-class debugging support too, which is great.) Now we have Vulkan as the new home for experimentation and it has great debugging and validation layers, while D3D pushes forward on certain new features and provides a more consistent baseline on Windows desktops. For console games as well, you can use Vulkan on (AFAIK) Nintendo Switch, while using D3D12 on Xbox, so each API is providing value for console game devs as well.
- bitwize 4y ago
  > OpenGL's freeform experimentation and evolution with extensions let people test things out in production environments to figure out what worked Yeah, except nobody did this. The cutting-edge features came to Direct3D first because Microsoft had early access to what the GPU vendors were doing and could plan out what that would look like from an API perspective. The vendor extensions only came out around the same time as the DirectX support, maybe later. Core OpenGL support would onlu emerge years later. > As a game developer it's invaluable to be able to swap over to a Direct3D backend for debugging even if you end up using OpenGL as your default. What? Name a game developer who's done this in the past 20 years -- use Direct3D for debugging and OpenGL as the default. Only Id Software actually used OpenGL and Vulkan seriously, and they are owned by Microsoft now so that will change.
  - smoldesu 4y ago
    > Name a game developer who's done this in the past 20 years I'd imagine it was really popular among console developers, who would usually develop two versions of their game anyways (a DirectX one for Xbox/PC and an agnostic one for Mac/Playstation/other). DirectX is traditionally considered easier to use (and comes with PC tooling) so I could see how people would prefer it for debugging.
    - pjmlp 4y ago
      Contrary to urban myths OpenGL was never a thing in most game consoles. Sony only supported it on PS 2, and quickly moved into LibGNM(X) as almost no one cared, Nintendo had a OpenGL like API on the Wii, and while the Switch supports GL 4.6/Vulkan, its main API is NVN.
      - kevingadd 4y ago
        IIRC there was an OpenGL layer for PS3, but it was terrible and I only know of one (indie) dev who shipped a full-blown game on it. It was an awful experience from my understanding.
  - kevingadd 4y ago
    Before Vulkan, if you wanted to do graphics debugging like step-through on pixel shaders, your options were Direct3D + PIX or, if you had access to them, game console dev tools. Maybe Apple had something? Obviously, lots of games only had an OpenGL backend. So those devs simply didn't have access to those tools. It's the one outlier API with bad tooling.
    - pjmlp 4y ago
      See Instruments for macOS, and tooling from GPU vendors. The main problem with Khronos APIs has always been "go fishing" attitude, Vulkan isn't much better, even with the LunarG SDK.
- conspiranalyst 4y ago
  Isn't DX 11 the same as OpenGL 1.1 whereas DX12 is OpenGL 1.2? Edit, I might be mixing up OpenCL 1.1/1.2
  - kaetemi 4y ago
    DX11 is like modern OpenGL, DX12 like Vulkan. (OpenGL 1.x/2.x is ancient, and comparable to DX8/9. All still used by old software, though.)
  - magicalhippo 4y ago
    I still recall oh so many OpenGL apps failed to start when OpenGL 2.0 was released, as 1.x had been around for so long "everyone" had gotten used to just checking the minor version number.
shmerl 4y ago
I'm aware of history of DX12. It started as a clone of Mantle, which they made with full knowledge that Vulkan is going to be a thing. No one stopped them from collaborating on Vulkan instead which originated in Mantle the same way. I see no excuse here but the classic NIH / lock-in push. For the reference: https://twitter.com/renderpipeline/status/581086347450007553 https://twitter.com/renderpipeline/status/581086347450007553
- MindSpunk 4y ago
  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.

You are aware of the history of DX right? Their SDK is old and really good. Just because Vulkan exist doesn't mean DX is invalid. Good to have more than one thing. Innovation and stuff

kevingadd 4y ago

Arguably without the OpenGL vs D3D and now Vulkan vs D3D back and forths, along with experimental APIs like MANTLE, we definitely wouldn't have a lot of the robust tech we have access to today. OpenGL's freeform experimentation and evolution with extensions let people test things out in production environments to figure out what worked, while D3D's stable feature set meant that games and productivity software could - if it made sense for the developer - choose to ship a more limited feature set that worked everywhere, all of the time. D3D also has consistently offered great debugging tools and a robust reference rasterizer, things you simply can't get in an OpenGL environment. As a game developer it's invaluable to be able to swap over to a Direct3D backend for debugging even if you end up using OpenGL as your default. (These days, Vulkan has first-class debugging support too, which is great.) Now we have Vulkan as the new home for experimentation and it has great debugging and validation layers, while D3D pushes forward on certain new features and provides a more consistent baseline on Windows desktops. For console games as well, you can use Vulkan on (AFAIK) Nintendo Switch, while using D3D12 on Xbox, so each API is providing value for console game devs as well.

bitwize 4y ago
> OpenGL's freeform experimentation and evolution with extensions let people test things out in production environments to figure out what worked Yeah, except nobody did this. The cutting-edge features came to Direct3D first because Microsoft had early access to what the GPU vendors were doing and could plan out what that would look like from an API perspective. The vendor extensions only came out around the same time as the DirectX support, maybe later. Core OpenGL support would onlu emerge years later. > As a game developer it's invaluable to be able to swap over to a Direct3D backend for debugging even if you end up using OpenGL as your default. What? Name a game developer who's done this in the past 20 years -- use Direct3D for debugging and OpenGL as the default. Only Id Software actually used OpenGL and Vulkan seriously, and they are owned by Microsoft now so that will change.
- smoldesu 4y ago
  > Name a game developer who's done this in the past 20 years I'd imagine it was really popular among console developers, who would usually develop two versions of their game anyways (a DirectX one for Xbox/PC and an agnostic one for Mac/Playstation/other). DirectX is traditionally considered easier to use (and comes with PC tooling) so I could see how people would prefer it for debugging.
  - pjmlp 4y ago
    Contrary to urban myths OpenGL was never a thing in most game consoles. Sony only supported it on PS 2, and quickly moved into LibGNM(X) as almost no one cared, Nintendo had a OpenGL like API on the Wii, and while the Switch supports GL 4.6/Vulkan, its main API is NVN.
    - kevingadd 4y ago
      IIRC there was an OpenGL layer for PS3, but it was terrible and I only know of one (indie) dev who shipped a full-blown game on it. It was an awful experience from my understanding.
- kevingadd 4y ago
  Before Vulkan, if you wanted to do graphics debugging like step-through on pixel shaders, your options were Direct3D + PIX or, if you had access to them, game console dev tools. Maybe Apple had something? Obviously, lots of games only had an OpenGL backend. So those devs simply didn't have access to those tools. It's the one outlier API with bad tooling.
  - pjmlp 4y ago
    See Instruments for macOS, and tooling from GPU vendors. The main problem with Khronos APIs has always been "go fishing" attitude, Vulkan isn't much better, even with the LunarG SDK.
conspiranalyst 4y ago
Isn't DX 11 the same as OpenGL 1.1 whereas DX12 is OpenGL 1.2? Edit, I might be mixing up OpenCL 1.1/1.2
- kaetemi 4y ago
  DX11 is like modern OpenGL, DX12 like Vulkan. (OpenGL 1.x/2.x is ancient, and comparable to DX8/9. All still used by old software, though.)
- magicalhippo 4y ago
  I still recall oh so many OpenGL apps failed to start when OpenGL 2.0 was released, as 1.x had been around for so long "everyone" had gotten used to just checking the minor version number.

shmerl 4y ago

I'm aware of history of DX12. It started as a clone of Mantle, which they made with full knowledge that Vulkan is going to be a thing. No one stopped them from collaborating on Vulkan instead which originated in Mantle the same way. I see no excuse here but the classic NIH / lock-in push. For the reference: https://twitter.com/renderpipeline/status/581086347450007553 https://twitter.com/renderpipeline/status/581086347450007553

MindSpunk 4y ago
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.