"Dozen" Merged Into Mesa For Implementing Vulkan On Direct3D 12

[Rccero]

For reference:
Nintendo's Switch actually has official Vulkan support, yet, AFAIK, not a single commercial game is making use of it.

(Probably because it has a nVidia Maxwell GPU, which is badly suited for running Vulkan loads in the first place.)

Actually, at least some commercial games use it, all retro: Super Mario 3D All-Stars (Mario 64, Sunshine and Galaxy run ontop an emulator that uses Vulkan), the n64 games in Switch Online Service (the same), Turok 2 and Doom 64 re-releases (idem)...

I've also read some Vulkan PC games that were ported to Switch (Doom Eternal, No Man's Sky, Hades) might have kept using the API in the handheld console, but as far as I know that's not confirmed.

[Awesomeness]

Windows@ARM devices only have DX12.

Xbox does not support Vulkan either.

Nobody is stopping Microsoft to add Vulkan to those products. I think it's BS to add a wrapper to Mesa just because Microsoft can't get their departments in line.

[Guest]

Nobody is stopping Microsoft to add Vulkan to those products. I think it's BS to add a wrapper to Mesa just because Microsoft can't get their departments in line.

It's maintenance burden; if Vulkan has a new version that just breaks compatibility with older releases or something dramatic, Microsoft has to then maintain the older codebase and a newer one, on-top of whatever other changes Vulkan might have, and the inverse is also true (If MS changes how they handle 3rd-party graphics APIs). Vulkan is a graphics API that Microsoft doesn't directly support or have any control over. Meanwhile, they support DX12 across all their platforms, and are confident enough in it to wrap OpenGL, OpenCL, and now Vulkan to it.

The mess of graphics APIs available is tolerable on PC to some extent (lol OpenGL), but that's not acceptable for any other platform (Surface, S, Xbox).

Basically, I doubt some inexperienced intern up and decided one day to make some project to be used by a major operating system for fun and then had people toss 15K lines of code at it. This isn't some basement hobby project.

[skeevy420]

I'm loling at the thought of some Wine/Linux setup going Vulkan >Dozen> Direct3D 12 >VKD3D12> Vulkan

[Quackdoc]

Nobody is stopping Microsoft to add Vulkan to those products. I think it's BS to add a wrapper to Mesa just because Microsoft can't get their departments in line.

why? mesa has zink, is that not BS? if not, then why? because it will get used on linux? so will this, this will likely help with WSL2 and hyper-v. and considering that mesa isn't a linux only project in the first place, I think thats a moot point anyways. I'm rather happy to see it added to mesa, so now that mesa devs have say on the development direction instead of just MS. I would like FOSS to infect everything myself and this is good to see in my books.

[dragorth]

I wonder whats the value of a vulkan to D3D12 layer if, if there is no D3D12 implementation in Mesa. I mean even for testing it's kind of pointless, isn't it? Can the Mesa people even test if this thing works? How does CI look like? How to be sure that a change in Mesa doesn't kill the layer? I'm not sure if this platform specific "module" wouldn't be better off out of tree.

I'm not saying it's bad or that Microsoft should stay away from Mesa, I just cant see the benefit and on the other hand I can see this to be a major roadblock because of testing / test integration in the future.

Mesa is using D3D12 as a backend. Mesa is OS agnostic, and can be compiled for Windows. It is what MS is basing their OpenGL Angle on, as well as other projects.

[Ladis]

Nobody is stopping Microsoft to add Vulkan to those products. I think it's BS to add a wrapper to Mesa just because Microsoft can't get their departments in line.

Others answered it, too many complications. Their chosen solution is similar to them adding OpenGL ES in the past: a library (fork of ANGLE) and a prepared Visual Studio solution bundle. The developer has all control what version to use and can edit the opensource code.

[DRanged]

What we need for this is gpu acceleration, in which case we might get it when qemu finally get vulkan support. windows VM in vmware on linux host is a fine experience. QEMU can be very slow to implement technology sometimes, and really fast and uncessary technology often gets dropped or left in an unusable state, like the qemu vmsvga driver. which stopped working during WinXP lifetime.

You forgot to mention VirtualBox too

[Quackdoc]

You forgot to mention VirtualBox too

well virtualbox isn't a very good vm software. I don't remember the last time VBOX actually did any really innovation, they seem to be on perma maintenance mode, the cpu preformance is inferior to both qemu and vmware, and the vgpu is also trash. being dx9 only, I actually get better use out of qemu with software acceleration anyways xD. but needless to say, I use qemu for any unix based VMs, and vmware for windows. unless I use gpu passthrough. the vbox changelog paints a bleak picture IMO

[qarium]

the one who trust microsoft practices,,,

https://www.theverge.com/2022/3/25/22995144/microsoft-foreign-corrupt-practices-bribery-whistleblower-contracting