Mesa's "Dozen" Close To Providing Vulkan Over Direct3D 12

[s_j_newbury]

Maybe the XBox? Though that seems like the wrong target for this...


Wasn't Gallium3D created by Tungsten before they were bought by VMWare?

Yes, it was.

[dragon321]

What's the end goal here?

As in: Is there a nefarious purpose (EEE) or is it more like simple practicality in terms of wanting to be able to emulate/virtualise WSL2 on top of existing DX12 Windows closed-source driver infra when using Vulkan-native apps inside WSL2?

If it's not clear from the context, I'm leaning towards the latter FWIW.

There is also one more thing. Windows natively doesn't support neither modern OpenGL or Vulkan. If I recall correctly it only supports OpenGL 1.1 (Windows NT intially supported only OpenGL) and newer versions or other APIs are provided by drivers via Installable Client Driver (ICD). That's how it's working on x86 Windows. On other Windows based platforms (Windows ARM or Xbox) only natively supported APIs are available and drivers are not providing implementation for others. That makes only Direct3D as available API (also OpenGL 1.1 but I think I don't have to explain why it's not very good choice). No Vulkan or modern OpenGL unless you implement these APIs on top of Direct3D. We already have pack for OpenGL and OpenCL and now it's time for Vulkan. Yes, native implementation would be nice thing but as long Direct3D is existing and popular then Microsoft don't really has any reason to support it natively and it's better to have it on top of Direct3D than don't have it at all.

[Quackdoc]

There is also one more thing. Windows natively doesn't support neither modern OpenGL or Vulkan. If I recall correctly it only supports OpenGL 1.1 (Windows NT intially supported only OpenGL) and newer versions or other APIs are provided by drivers via Installable Client Driver (ICD). That's how it's working on x86 Windows. On other Windows based platforms (Windows ARM or Xbox) only natively supported APIs are available and drivers are not providing implementation for others.

"natively supports" means baking it into their proprietary driver stack, as for vulkan it's self, it's supported as well as dx12 is from the OS's interpretation of it, the reason they don't support vulkan is because micro$oft says no. just like gpu providers need to provide an ICD for vulkan, they also need to provide a UMD, which sits between d3dxx.dll and dxgi.dll, dxgi talks directly to d3dkmt, I believe vulkan icd does as well, (though there may be a layer of abstraction, like gdi32 for OGL).

in the end, it's a way for windows to push towards their pseudo utopian OS ecosystem, much like mac and osx

[dos1]

It's obvious - Mike is gonna get Zink running on it for the ultimate in indirection!

...then you'll be able to run WineD3D on it, with old DirectX games working that don't work on Windows natively anymore

[smitty3268]

Wasn't Gallium3D created by Tungsten before they were bought by VMWare?

Fair enough, yeah. Actually I don't know what their business model was.

[johnp]

There is no reason for Mesa to not accept Microsoft's free software code (open source).

The logic of Free Software, is the user to have access to the source code of the software he uses, so as to be able to adapt it to his needs, if needed.

For example, source code is contributed to the Linux kernel, by Google, for Android operating system functionality.

The user is not obliged to use the code contributed by Microsoft to Mesa. He can run some real Linux distribution, FreeBSD, or some other OS where Mesa works.

[microcode]

What's the end goal here?

As in: Is there a nefarious purpose (EEE) or is it more like simple practicality in terms of wanting to be able to emulate/virtualise WSL2 on top of existing DX12 Windows closed-source driver infra when using Vulkan-native apps inside WSL2?

If it's not clear from the context, I'm leaning towards the latter FWIW.

They are also trying to enable Android on Windows, not just developer stuff or desktop Linux apps; Vulkan is part of the basic Android platform as of a few versions ago, so in order to ship a recent Android distribution, you need a working Vulkan driver.

[microcode]

Maybe they finally can prevent vendor OpenGL, OpenCL and Vulkan implementations to be used in Windows and force everybody to write DirectX drivers only. More or less Metal does it in MacOS. So yes, we can finally have an EEE here in the middle term future.

No, in general D3D12 is missing things that would make this viable for general Vulkan use. Vendors will continue to work on Vulkan drivers. OpenGL may age out of needing direct implementations, but if they're building mesa on Windows to accomplish that, they're more likely to use Zink than the other thing.

Also keep in mind, this work only runs inside WSL for now, so it's not as though it's really useful as a replacement for Vulkan drivers on Windows anyway.

[dragon321]

"natively supports" means baking it into their proprietary driver stack, as for vulkan it's self, it's supported as well as dx12 is from the OS's interpretation of it, the reason they don't support vulkan is because micro$oft says no. just like gpu providers need to provide an ICD for vulkan, they also need to provide a UMD, which sits between d3dxx.dll and dxgi.dll, dxgi talks directly to d3dkmt, I believe vulkan icd does as well, (though there may be a layer of abstraction, like gdi32 for OGL).

in the end, it's a way for windows to push towards their pseudo utopian OS ecosystem, much like mac and osx

DirectX is part of Windows API and it's provided by Windows itself. Drivers are responsible for providing backend that's right, but API itself is part of Windows. Neither Vulkan or modern OpenGL are part of Windows - you need external implementations to have them and they are not necessary for Windows to function. They are not even available on every Windows based platform. Windows x86 simply doesn't block drivers developers from providing support for another API. And we are speaking about Win32 here because UWP doesn't support any other graphics API than Direct3D even on x86.

[Quackdoc]

DirectX is part of Windows API and it's provided by Windows itself. Drivers are responsible for providing backend that's right, but API itself is part of Windows. Neither Vulkan or modern OpenGL are part of Windows - you need external implementations to have them and they are not necessary for Windows to function. They are not even available on every Windows based platform. Windows x86 simply doesn't block drivers developers from providing support for another API. And we are speaking about Win32 here because UWP doesn't support any other graphics API than Direct3D even on x86.

they are not available on every windows based platform because windows says no to it. from a userland app's perspective, whether that be a game or compute application, it doesn't care what provides the API, as long as it shoots the calls and something is there. the reason there is no vulkan support for a lot of these things, is because windows goes out of their way to make it a "no go"