Hacker News Reader

Comment by christoph-heiss | Hacker News Reader

FYI:

This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The driver exposes a paravirtualized GPU to user mode applications running in a virtual machine on a Windows host. This enables hardware acceleration in environment such as WSL (Windows Subsystem for Linux) where the Linux virtual machine is able to share the GPU with the Windows host.

So this isn't actual "DirectX on Linux", just a driver for a virtual GPU exposed to WSL-guests to enable guests to directly use DirectX, more or less.

Probably most useful for Azure-based projects.

View on HN

No, if you read the blog post on Microsoft's site it goes into more detail:

This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target. It offers the same level of functionality and performance (minus virtualization overhead).

It says 4 sentences earlier:

>> Linux when running in WSL.

>> minus virtualization overhead

refers to "para" in "paravirtualization." "Paravirtualization" is reducing the overhead of virtualization when the guest knows it's being virtualized.

That's the user space code. It still depends on the Windows drivers to do the work.

This sounds like an attempt to win back ML segment from Linux to Windows. There are three letters back in my mind that sound like screaming, but too early to tell unfortunately.

In this case, this is the extend phase. So this is what they really mean about 'using Linux' and 'Microsoft <3 Linux'.

How is it too early to tell?

It is an extension of the capability of WSL, giving you that sweet convenience of the DirectX API with your existing ML project. Of course, this extension makes your project incompatible with desktop Linux once adopted.

Not necessarily. It is not possible to access the GPU in WSL at all right now, so I need to dual boot which also means dealing with Linux desktop compatibility issues with my laptop. As long as I can use the same ML framework (without DirectX API), then this poses no compatibility issues at all. It just means I can develop & run my ML code in WSL.

Just curious, what stops your ML code from running under Windows?

It's way more of a pain, due to a lot of legacy constraints in windows. It's easy to overflow pathnames and command lines that then get silently truncated. Doing ML dev work is for sure easier on a Linux env than a pure Windows env. it's not impossible on Windows, but def much nicer in Linux.

Except your ML project is accessing the DirectX API through another cross-platform API layer (CUDA). And the purpose of running WSL is that you ultimately hope to deploy to Linux servers (which Microsoft hopes will be on Azure).

The thing with WSL is that it doesn't win back the ML segment from Linux to Windows for production workloads. This is just a developer workstation friendly move that explicitly doesn't tie you to Windows itself.

It seems like Microsoft is continuing to see Linux as a production server target while positioning Windows to remain relevant as a workstation OS.

Ostensibly, this is a move to compete with Mac OS and not Linux.

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).

Mentioned it in another comment, but I am not sure what stoped people from doing ML without WSL. I don't even know ML libraries, that don't work on Windows proper.

Reply on news.ycombinator.com