I'm not too sure about that, what about the support for DX12 in WSL? Can't deploy that to production outside WSL right now as far as I'm aware, unless they add DX12 support to azure Linux vms...

Given that the main use case is stuff like running machine learning tools, the only people directly targeting DX12 on WSL will probably be framework/library developers, who might want to add DX12 as one of the graphics systems they support. If that's the case, the vast majority of developers won't notice any difference other than more software supporting graphics acceleration when run in WSL (or, another way of looking at it, when Linux is running on the WSL "hardware"/"platform").

Sure, nothing stops you from targeting DX12 directly in your application code, but why would you do that? At that point, you'd just target Windows since your users would have to be running it anyway.

> I'm not too sure about that, what about the support for DX12 in WSL?

It's an implementation detail -- they're exposing the Windows graphics driver to the Linux system with the most minimal amount of translation and overhead.

You could code directly to it in your Linux application code but it makes no sense to do that. You'd be literally writing a Linux application that can only run under Windows -- the smallest market ever proposed. Instead library/framework developers will add it as another target to improve performance in WSL for generic Linux applications.

> This is just a developer workstation friendly move that explicitly doesn't tie you to Windows itself.

Ah, but it does tie the developer to Windows ~ this DirectX module can only be used with WSL2, which only runs on Windows.

No, because developers won't be coding to this DirectX module directly. They'll be using CUDA or OpenGL or using another library or framework for which this is just one of many backend implementations.

Unless you think developers would actually bother coding explicitly for the world smallest possible market (Linux inside of Windows).