Good. Now if Windows would adopt Vulkan as the graphics API of the future.
I don't dislike Vulkan either, it's just that I don't see the point of replacing something that works pretty well.
Same reason standards have some value.
But that's going to be in quite a while since I can't think of an actual feature (for end users) that is missing from one vs the other right now.
Everything on Windows already uses d3d12/DirectX basically so it would actually be a huge wheel reinvention to migrate to a standard just for the sake of it.
They already made the first sensible step with SPIR-V here. The next step makes the same sense.
And stuff can be translated into Vulkan if it can't be rewritten.
AMD and DICE developed a prototype API called Mantle. Which is what both DX and Vulkan are based on.
Both Vulkan(glNext back then) and DX12 were announced around the same time. VK came a bit later as standards are usually slower in coming to decisions but it's not like VK was reinventing anything from DX.
I remember we were having a laugh reading early DX12 documentation as it was in parts just copied from Mantle with names unchanged in places!
I wonder if that means that dx12 and Vulkan could have a good interop/compatibility story, since they both have similar origins.
> Vulkan 1.0 was released in February 2016.
What people forget is that Mantle was basically a proprietary AMD API that they wanted and developed until, well, the release of Metal in 2014 and DX 12 in 2015.
Only then did they "graciously" donated Mantle to Khronos for the development of modern APIs.
Vulkan was not just late. It suffers from the same issues as OpenGL before it: designed by committee, lackluster support from the major players.
Opening stuff up formally also takes time. So it all was going towards Vulkan in one form or another and no one was forcing MS to push DX12 NIH while this was happening.
And counter to your point, despite Mantle being "proprietary", MS directly used it to create DX12 (same as Vulkan used it), so AMD clearly didn't have any complaints about that.
Was it an indication or was there any actual work done? Such as supporting anything else but AMD cards for example, inviting others to collaborate etc.?
> despite Mantle being "proprietary", MS directly used it to create DX12
I can't remember the term for it: what do you call when a single company develops something with little to no external input and collaboration, even if it's sorta kinda open?
As for "NIH"... Microsoft has/had a much bigger investment and interest in new gaming APIs than the few AMD cards that Mantle supported. And they already had their own platform, their own APIs etc. Makes sense for them to move forward without waiting for anyone
MS just decided to do that whole thing for their NIH in parallel using parts of Mantle practically verbatim. It wouldn't have been possible without AMD basically allowing it.
See: https://x.com/renderpipeline/status/581086347450007553
I.e. I don't see any reason here for MS not to collaborate on Vulkan instead, besides the usual lock-in approach.
I would say that if you want to have multi-platform support just use Vulkan. Covers most of the platforms(especially if you include MoltenVK)[0].
Though, for games, if you want to support Xbox, that usually throws a curveball into API choice planning. As that might be more important of a target than Linux/Android/Mac/iOS(maybe even combined) for your game. So if you already have to support DX for that..
If and only if the GPU vendor supports it (they do for now). Windows itself fully supports only DX
> Though, for games, if you want to support Xbox, that usually throws a curveball into API choice
As does Playstation. Very few develop with Vulkan for Playstation as GDN (or whatever the name of the native framework is) is the main choice.
And on mobile, well, you need to support Metal.
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
Most importantly, Windows includes a software D3D renderer (WARP) so apps can depend on it always being present (even if the performance isn’t spectacular). There are lots of situations where Vulkan isn’t present on Windows, for example a Remote Desktop/terminal server session, or machines with old/low-end video cards. These might not be important for AAA games, but for normal applications they are.
Another example: Windows doesn’t include the Vulkan loader (vulkan-1.dll), apps need to bundle/install that.
sure, but addressing the two points that you brought up would not entail changing windows _the operating system_, just the stuff that ships with it. you could easily ship swift shader along with warp and the loader library, both of those are just some application libraries as far as the os/kernel is concerned. of course now we're in the territory of arguing about "what constitutes an OS" :-)
Why do you say that?
Another problem with being an open API is that (and this is my own speculation) it's easier for IHVs to collaborate with just Microsoft to move faster and hammer out the APIs for upcoming novel features like work graphs for example, vs bringing it into the public working group and "showing their cards" so to speak. This is probably why vk gets all new shiny stuff like rtrt, mesh shaders etc. only after it has been in d3d for a while.
One could argue this is all solvable by "just" adding a torrent of extensions to vulkan but it's really not clear to me what that path offers vs d3d.
In the end it might have even speed up the adoption of such features. Currently if you have a multiplatform engine, even though windows is like 99% of your PC player base it's still sometimes a tough decision to just use a feature that you can't support on all your targets.
edit: yup https://vulkan.gpuinfo.org/listreports.php?devicename=Micros...
Vulkan is not a well designed API. It's so complicated, verbose, and error prone. It's pretty bad.
And while they're much better than nothing, those documents are certainly not a specification. They're are individual documents each covering a part of the API, with very spotty coverage (mostly focusing on new features) and unclear relationship to one another.
For example, the precise semantics of ResourceBarrier() are nowhere to be found. You can infer something from the extended barrier documentation, something is written in the function MSDN page (with vague references to concepts like "promoting" and "decaying"), something else is written in other random MSDN pages (which you only discover by browsing around, there are no specific links) but at the end of the day you're left to guess the actual assumptions you can make.
*EDIT* I don't mean to say that Vulkan or SPIR-V specification is perfect either. One still has a lot of doubts while reading them. But at least there is an attempt of writing a document that specifies the entire contract that exists between the API implementer and the API consumer. Missing points are in general considered bugs and sometimes fixed.
I guess that's why Microsoft calls it an "engineering spec", but I prefer that sort specification over the Vulkan or GL spec TBH.
> The interface exists precisely to isolate the API consumer from the implementation details.
In theory that's a good thing, but at least the GL spec was quite useless because concrete drivers still interpreted the specification differently - or were just plain buggy.
Writing GL code precisely against the spec didn't help with making that GL code run on specific drivers at all, and Khronos only worried about their spec, not about the quality of vendor drivers (while some GPU vendors didn't worry much about the quality of their GL drivers either).
The D3D engineering specs seem to be grounded much more in the real world, and the additional information that goes beyond the interface description is extremely helpful (source access would be better of course).
Many of D3D12's newer features (Enhanced Barriers, which are largely a clone of Vulkan's pipeline barriers) are woefully under specified, with no real description of the precise semantics. Just finding if a function is safe to call in multiple threads simultaneously is quite difficult.
We're talking here about potential DX replacement, not about design in general and the bulk of it is very similar for both APIs.
There are some small quirks from Vulkan being made to be easily extensible which in the end I consider worth it.
I personally like how consistent the API is in both patterns and naming. After using it for a while, it's easy to infer what function will do from the name, how it will handle memory, and what you'll need to do with that object after the fact.
I find documentation better than the DX one.
What are your biggest problems with it?
What are the parts that you consider objectively better in D3D12 compared to Vulkan?