Not anymore so than they're already locked into CUDA. It's more a WDDM bridge than a strict DirectX bridge.

I don't see how being "locked into CUDA" should make one less skeptical of a change that will functionally lock projects into Windows. I can't help but think this is going to siphon resources from Linux native graphics development.

I don't see how it'll be locking projects into windows. There's no user space DirectX library here.

The whole point looks to take your CUDA code that would run just fine on Linux without a hypervisor, and run it just as well in WSL2.

ie. this is at worst still the embrace stage, IMO.

They are providing libd3d12.so, that is a user space library that apps can link to.

At the moment, that library only works under WSL, but I guess the DXVK folks can connect their implementation too.

> The plan is for Microsoft to provide shims to allow the existing Linux userspace interact with DX12; I'll explain below why we had to pipe DX12 all the way into the Linux guest, but this is not to introduce DX12 into the Linux world as competition. There is no intent for anyone in the Linux world to start coding for the DX12 API.

https://lkml.org/lkml/2020/5/19/1139

And backing that up, they ported Mesa to get OpenGL and OpenCL in the Linux guest and are working on a Vulkan port as well.

We've changed from https://lkml.org/lkml/2020/5/19/742 to the blog post it links to, which hopefully makes things clearer.