DirectX Developer Blog

This adds more to the evidence that Vulkan / DX12 seems like a failed API design, when too many graphics engineers are reinventing the wheel by building their render-graph API on top of these (propietary triple-A game engines, Unreal Engine, and now Godot...) Instead of real-time graphics APIs providing all these low-level manual synchronization primitives and cumbersome PSOs, maybe they should just provide an official Render Graph API instead? Provide all of the operations and its dependencies in an acyclic graph up-front, and the driver handles synchronization automatically in the most performant manner tailored to the hardware.

I guess there needed some trial-and-error in the gamedev world for about a decade to really nail down a nice to use but also performant graphics API design. Vulkan being originated from the Mantle API from AMD didn't help - since it was a low-level console API mainly accustomed to AMD's GPUs and really didn't seem like it would fit for a more "general-purpose" API spanning a huge range of hardware and can stand the test of time. And with Microsoft's DX12 hastely copying from AMD's initial design it also has all the same issues (The irony is that DX11 is still the best graphics API you can use in gamedev in Windows in terms of ergonomics and even performance - seeing many trying to dauntingly build a DX12 backend and end up performing worse than DX11...)

Nowadays I'm obversing that the industry has known these issues for a while and are…

Great article. Would like to see this become a reality.

I'm not so sure about this idea though, if Microsoft would ever take this path, it'll probably be far far in the future.

I think Microsoft releases and Edge version for Linux in an attempt to get Linux users on board to use their products. People using this will probably be less reluctant to try other Microsoft products as well.

Edge is based on Chromium, which is already Linux native. It probably took Microsoft minimal effort to release a Linux binary as well, making this a win-win situation for them.

Now to strengthen that argument; Microsoft did not release any other enduser software for native Linux yet, such as Office or other Windowws native tools. At least, I'm not aware of any. Maybe this is something they'll take on in the future, only one can dream. Now I know there's .NET Core and PowerShell, but I'd hardly call that enduser software.

At the same time they're working on various things that seem like a vender-lockin. I'll give two examples.

The first is the Windows/Microsoft Store and UWP. More and more applications (and AAA games) are released through this store as UWP apps. These UWP apps (and the store) cannot be emulated (yes I know Wine is not an emulator) on a Linux host at this moment and function as a DRM layer, nor do I think this will happen anytime soon.

As second example, take DirectX. Microsoft recently showed plans for supporting DirectX on Linux…

> Its definitely the same on Windows as it always was, which is the platform I most developed games for.

Not really. Most games use "borderless windowed" mode instead of fullscreen exclusive, and even FSE is not true exclusive mode anymore in most cases.

https://devblogs.microsoft.com/directx/demystifying-full-screen-optimizations/

> When using Fullscreen Optimizations, your game believes that it is running in Fullscreen Exclusive, but behind the scenes, Windows has the game running in borderless windowed mode. When a game is run in borderless windowed mode, the game does not have full control of the display– that overarching control is given back to the Desktop Window Manager (DWM).

see also https://learn.microsoft.com/en-us/windows/win32/direct3ddxgi/for-best-performance--use-dxgi-flip-model

It's been a long time since I used Chrome on Windows — do you know if Chrome's fullscreen mode leverages exclusive fullscreen/fse/fullscreen optimizations[0]?

I'm pretty sure that's what most games use to bypass the forced DWM vsync. For example, when I used Dolphin on one of those cheap 60hz IPS LCD monitors with no internal scaler, I always preferred the lower latency + tearing in exclusive fullscreen compared to the laggy + smooth windowed mode. There was honestly such a stark difference between the two that I found the game to be unplayable in DWM's windowed vsync mode.

[0]: https://devblogs.microsoft.com/directx/demystifying-full-screen-optimizations/

edit: to answer my own question, it looks like Chrome does not use exclusive fullscreen https://news.ycombinator.com/item?id=28784108

The Agility SDK is unrelated to what is being discussed here. It is a delivery mechanism for the Direct3D 12 runtime instead of DXGI, it is opt-in from the application side, and is done through a more stable loader stage in the core OS instead of hot-patching.

It does, however, give insight into the situation that the DirectX team is in. The in-box version of D3D12Core in the latest version of Windows 11 is SDK version 612. This can be compared against the released Agility SDK versions:

https://devblogs.microsoft.com/directx/gettingstarted-dx12agility/

SDK version 612 is just before the 613 Agility SDK release on 3/11/2024. This means that the version of DirectX 12 they are able to ship in the main OS is a year and a half behind the latest released version.

Yeah, that's more or less correct.

> The new combined shader will be named "Mesh" shader

It's only new for Vulkan. On Windows and XBox, mesh shaders were implemented couple years ago:
https://devblogs.microsoft.com/directx/coming-to-directx-12-mesh-shaders-and-amplification-shaders-reinventing-the-geometry-pipeline/

This new Vulkan extension is a direct copy-paste of the above, leveraging the same hardware.

However, the hardware support for mesh shaders is less than ideal. That thing needs feature level 12.2, so-called "DirectX 12 Ultimate".
It only works on nVidia Turing (GeForce 20 series) or newer, and AMD RDNA2 (Radeon RX 6000 series, and current generation of game consoles).