4 ms·
Ten Years of D3D12
- shmerl 1y agoIt should have been Vulkan from the start instead of another NIH.
- rahkiin 1y agoDx12 was release 2 years before Vulkan… And there are plenty of advantages to having control over an API instead of putting it in some slow external organization without focus
- pjmlp 1y agoVulkan only exists because DICE and AMD were nice enough to contribute their Mantle work to Khronos, otherwise they would still be wondering what OpenGL vNext should look like.
- HexDecOctBin 1y ago> otherwise they would still be wondering what OpenGL vNext should look like. And the world would have been a better place. All we needed in OpenGL 5 was a thread-safe API with encapsulated state and more work on AZDO and DSA. Now, everyone has to be a driver developer. And new extensions are released one-by-one to make Vulkan just a little more like what OpenGL 5 should have been in the first place. Maybe in 10 more years we'll get there.
- kg 1y agoIMO without SPIR-V, OpenGL 5 would still be at a disadvantage in many scenarios. It's possible we would have gotten widespread support for it even without Vulkan, though.
- HexDecOctBin 1y agoOpenGL supports SPIR-V: https://www.khronos.org/opengl/wiki/SPIR-V https://www.khronos.org/opengl/wiki/SPIR-V
- connicpu 1y agoI can't imagine the world without Vulkan because while it is a lot lower level and more difficult to work with, it makes things like DXVK not only possible but quite performant. Gaming on Linux has been accelerated super strongly by projects like that.
- pjmlp 1y agoGaming on Linux is doing just fine on Android/Linux. The problem is making gaming on GNU/Linux profitable, Vulkan will not fix that, while Proton is not a solution that will work out long term.
- mikestorrent 1y agoNothing is ever going to be profitable on GNU/Linux except for using it to drive SaaS and other such schemes. People that use Linux on the desktop are, on average, much less likely to want to pay for any kind of software; this has been true for 30 years... Steam might change this, we'll see.
- pjmlp 1y agoRelying on Microsoft being happy with Proton isn't a long term strategy, additionally no company management stays around forever.
- connicpu 1y agoIt doesn't matter what Microsoft thinks of Proton, Google v Oracle had a pretty solid outcome > In a 6–2 majority, the Court ruled that Google's use of the Java APIs was within the bounds of fair use, reversing the Federal Circuit Appeals Court ruling and remanding the case for further hearing. https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_...
- pjmlp 1y agoKeep wishing.
- pjmlp 1y agoI used to be a big OpenGL advocate all the way up to Long Peaks, eventually I came to realise it is another committee driven API, and writing a couple of plugin backends was never that much of a deal. Just see the shading mess as well, with GLSL lagging behind, most devs using HLSL due to its market share, and now Slang, which again was contributed by NVidia. Also the day LunarG loses out their Vulkan sponsorship, the SDK is gone.
- HexDecOctBin 1y agoOh, I agree that OpenGL 3 and 4 were absolute disasters, D3D11 is right there for how to do this mostly correctly, and OpenGL doesn't even stand close by comparison. But by the time 4.5 and 4.6 came out, things were going in the right direction. And then Vulkan killed the momentum. Imagine a OpenGL which takes inspiration from D3D11 and dares to be even more user-friendly and intuitive. Instead, we got Vulkan, yay.
- pjmlp 1y agoSpot on, and then on the Web we get 10 year delay on hardware capabilities, and still no debugging tools after 15 years.
- cyberax 1y agoHard disagree. OpenGL state management was unfixable if it had to keep compatibility with OpenGL 2. That's why OpenGL 3/4 ended up being such huge messes. The main problem with Vulkan is that Apple decided to go with its own Metal API, completely fracturing the graphics space.
- flohofwoe 1y agoOut of the modern non-console 3D APIs (Metal, D3D12, Vulkan), Vulkan is arguably the worst because it simply continued the Khronos tradition of letting GPU vendors contribute random extensions which then may or may not be promoted to the core API, lacking any sort of design vision or focus beyond the Mantle starting point. Competition for 3D APIs is more important than ever (e.g. Vulkan has already started 'borrowing' a couple of ideas from other APIs - for instance VK_KHR_dynamic_rendering (e.g. the 'render-pass-object-removal') looks a lot like Metal's transient render pass system, just adapter to a non-OOP C API).
- bobajeff 1y agoIt sounds like maybe Khronos should handle 3D APIs like they do with slang[1] and just host someone else's API such as Diligent Engine or BGFX and then let them govern it's development. [1]: https://shader-slang.org/ https://shader-slang.org/
- pjmlp 1y agoJust like with Mantle, Slang came to Khronos, because after they stated they would not be doing any further GLSL development, and it was up to the community to keep using HLSL or do something else themselves, a year later NVidia decided to contribute the Slang project.
- shmerl 1y agoYou can read about DX12 being worse here: https://themaister.net/blog/2021/11/ https://themaister.net/blog/2021/11/ But that's not even the point. Everyone could collaborate on the common API and make it better. Where were Apple and MS? Chasing their NIHs instead of doing it, so you argument is missing the point. It's not about how good it is (and it is good enough, though improving it is always welcome), it's about it being the only collaborative and shared effort. Everything else is simply irrelevant in result even if it could be better in some ways.
- HexDecOctBin 1y agoSeeing what a clusterf#ck OpenGL 3 and 4 were (and Vulkan ended up being), and how Direct3D 11 is probably the most usable 3D API right now, both Apple and Microsoft were absolutely right to chase their own APIs. If not for competition from Metal and D3D12, Vulkan would still be forcing render passes and static pipelines.
- dotnet00 1y agoI think Vulkan adoption was hurt by how much more complicated it was to use efficiently early on. Considering that DX12 made it out earlier, and it took some time for Vulkan to finally relax some of its rules enough to be relatively easy to use efficiently, I think it just lost momentum.
- bob1029 1y ago> Or at least, you can do that if you still care about MSAA. :) I am a huge fan of all traditional forms of supersampling, intra-frame-only anti-aliasing techniques. The performance cost begins to make sense when you realize that these techniques are essentially perfect for the general case. They actually increase the information content of each pixel within each frame. Many modern techniques rely on multiple consecutive frames to build a final result. This is tantamount to game dev quackery in my book. SSAA is even better than MSAA and is effectively what you are using in any game where you can set the "render scale" to a figure above 100%. It doesn't necessarily need to come in big scary powers of two (it used to and made enablement a problem). Even small oversampling rates like 110-130% can make a meaningful difference in my experience. If you can afford to go to 200% scale, you will receive a 4x increase in information content per pixel.
- CharlesW 1y agoI'm a huge fan too, but my understanding is that traditional intra-frame anti-aliasing (SSAA, MSAA, FXAA/SMAA, etc.) does not increase the information capacity of the final image, even though it may appear to do that. For more information per frame, you need one or more of: Higher resolution, higher dynamic range, sampling across time, or multi-sampled shading (i.e. MSAA, but you also run the shader per subsample).
- flohofwoe 1y agoMSAA does indeed have a higher information capacity, since the MSAA output surface has a 2x, 4x or 8x higher resolution than the rendering resolution, it's not a 'software post-processing filter' like FXAA or SMAA. The output of a single pixel shader invocation is duplicated 2, 4 or 8 times and written to the MSAA surface through a triangle-edge coverage mask, and once rendering to the MSAA surface has finished, a 'resolve operation' happens which downscale-filters the MSAA surface to the rendering resolution. SSAA (super-sampling AA) is simply rendering to a higher resolution image which is then downscaled to the display resolution, e.g. MSAA invokes the pixel shader once per 'pixel' (yielding multiple coverage-masked samples) and SSAA once per 'sample'.
- rmunn 1y agoMe, a tabletop RPG gamer and board gamer who hasn't played computer games in years (literally more than a decade): "Huh, that's interesting. Why are they rolling a 12-sided die between 1 and 3 times, choosing how many times it will be rolled by rolling a 6-sided die and dividing the number in half rounded up?" Because before I clicked on the article (or the comments), that's the only sense I could make of the expression "d3d12" — rolling a d12, d3 times.
- teucris 1y agoReally appreciate the detailed article! I was on the team that shipped D3D11 and helped with the start of D3D12. I went off to other things and lost touch - the API has come a long way! So many of these features were just little whispers of ideas exchanged in the hallways. So cool to see them come to life!
- robotnikman 1y agoOne of the features that was hyped about DirectX 12 was that it had explicit support for multiple GPU's even if they were different models from different manufacturers. As far as I know very few, if any, games currently take advantage of this feature. It's somewhat interesting that this is the case, when you think of it many PC's and laptops do have 2 GPU's, one as a Discrete Graphics card, and the other that comes integrated with the CPU itself (and over the last few year's these integrated GPU's have become powerful enough themselves to run some demanding games at low or medium settings at 60 fps)
- xgkickt 1y agoLast time I tried to do this (run iGPU as a compute coprocessor for the CPU) it was no longer supported, the driver enumerating both but forcing the use of one only.
- bob1029 1y agohttps://www.pcgamer.com/ashes-of-the-singularity-benchmark-unites-amd-and-nvidia-under-dx12sort-of/ https://www.pcgamer.com/ashes-of-the-singularity-benchmark-u...
- buyucu 1y agoThe future is Vulkan, not DirectX