Triton: DirectX 11 Driver for QEMU | Hacker News Reader

Triton: DirectX 11 Driver for QEMU

blog.getutm.app

215 pointselectricant49 comments

Reminds me of VirGL [1] and Venus [2], which I think do something similar for OpenGL and Vulkan.

I use this with Baguette/Crostini on ChromeOS to get some light gaming done. Works very well [3].

[1]: https://docs.mesa3d.org/drivers/virgl.html

[2]: https://docs.mesa3d.org/drivers/venus.html

[3]: For Baguette, the Crostini-replacement, one needs to do a minor amount of tweaking to get 3D acceleration to work well (https://www.reddit.com/r/Crostini/comments/1sftdu1/comment/o...).

That’s like (at least) third GPU-related project named Triton

I was expecting DirectX in triton-lang https://github.com/triton-lang/triton

Nobody named theirs Deuteron? (Sorry could not resist)

I seriously considered this name for a triton related project. Well there’s helion (metas autotuning dsl) at least.

Let's not forget the now defunct line of Trident graphics cards, dating back to the early 90s. Phonetically I thought they were talking about a driver for it.

Or Trident, which was (and maybe still is?) Joyent's flagship product in the private cloud space.

Nice, I've been waiting for something like this for years. Meanwhile the gaming scene on linux has been getting better slowly thanks to Valve and friends... but being able to boot into a Windows VM with graphics acceleration was previously a pain on Linux machines that only have a single discrete GPU - I'd wonder whether a solution like this would work with VirtualBox, or only on QEMU.

Pretty cool to finally have a decent open 3d solution for windows vms. Now if only someone made an opengl driver for older intel macosx vms...

People are working on it!

https://github.com/steelbrain/reims-vgpu

https://github.com/steelbrain/metal2vulkan

If they eventually support Snow Leopard or Tiger, that would fill the enormous emulation donut hole of PowerPC Mac.

Not exactly what you are looking for... but I am working on a 32 bit intel mac emulator. OpenGL support is pretty far along at this point.

Ooh, is this public anywhere? Definitely an area of interest of mine :)

Not yet. I'm working on getting a release out by the end of the year. It won't be open source but there will be a free trial.

Gotcha. I look forward to checking it out.

Does this mean DX1-10 are also supported? I've been struggling to play some DX3-7 games because of VirtualBox and VMware limitations and Win10+ backward compatibility gaps.

Article is quite long and technical, so it wasn't clear to me. That said, still great to hear Windows guests are getting some attention, especially from a long lived project that's proven it's not going anywhere.

Your options there are DOSBox-X, DOSBox Pure Unleashed, Winebox, WineD3D, DxWnd, DGVoodoo2 and my personal favourite, which is more in line with what you are talking about, SoftGPU.

SoftGPU is a DX capable driver for Win9x that runs on VMware and VirtualBox.

You'll get best compatibility for 20+ year Windows gaming using either

A) qemu with a XP/Vista guest and a older dedicated nvidia gpu pass thru.

B) Fully software using 86box/pcem but performance will suffer.

If the system requirements for those games are low and your host machine fast, your best bet is probably something like 86Box.

DX3-7 is now well supported with D7VK (fork of DXVK).

Likely such games will work better under Wine rather than modern Windows.

why always only DX11, why not DX12? Parallels and VMWARE can also do only DX11??

DX11 is much more high level while DX12 implements direct control over the GPU. 12 is much more like vulkan.

I guess since this is emulating the device instead of just passing the commands to vulkan it is easier to do DX11, but I could be wrong about this particular implementation.

DirectX 12 isn't just much more like Vulkan, it's so shockingly similar, it's basically Vulkan. It's jarring when you read it for the first time because you ask yourself why it even exists, but a second later, you realize it's so Microsoft can own their own graphics interface, too.

I could be remembering this incorrectly, but that's the impression I remember.

DX12 was over 2 years old by the time Vulkan was released. People in the industry also use DirectX extensively and have for decades (Vulkan is fairly marginal in comparison); many modern graphics API features (mesh shaders, ray tracing) were designed and developed in DirectX, as Microsoft worked with closely with ISVs on these features before they spread to wider audiences and published specifications.

Honestly if you are creating games, with the rise of Proton and vkd3d, there is seemingly less need to target Vulkan today than ever before. Just target x86_64 Windows with DirectX11 or DirectX12 and you will even get Linux support (and some day, probably macOS) "for free". That's just for games, though.

Vulkan existed before with AMD's Mantle or whatever was called.

Nope, thanks to AMD giving Mantle to Khronos, Vulkan actually happened, otherwise there would be no Vulkan now, they would still be arguing about OpenGL vNext on those committee meetings.

They look similar because both D3D12 and Vulkan have been 'influenced' by Mantle (Vulkan more strongly than D3D12 though).

Vulkan was released after both Metal and D3D12 btw.

And only exists in first place because AMD offered Mantle to Khronos, otherwise they would probably be discussing how OpenGL vNext would look like to this day.

While flohofwoe certainly knows this, for the others,

"Khronos is free to take as many pages as it wants out of the Mantle playbook, and AMD will impose no restrictions, nor will it charge any licensing fees."

-- https://www.phoronix.com/news/MTc2Mzc

There's that small thing of DirectX 12 predating Vulkan (and massively predating the useful Vulkan specs).

D3D11 is the by far most used 3D API on Windows (there are thousands of D3D11 games versus hundreds of D3D12 and much fewer Vulkan games), and most games don't actually have better performance with D3D12 or Vulkan anyway. So from a pragmatic 'bang for the buck' point of view, D3D11 both for the frontend and backend makes the most sense.

A pretty healthy proportion of games also shipped a DX11 renderer alongside their DX12 one, since the addressable audience of DX12 was pretty lousy for a long time

DX12 is much more complex to implement. Very different API.

Also covered here: https://www.phoronix.com/news/Triton-DirectX-11-QEMU-Driver

Maybe this is one of those topics to let an army of agents get loose.

Nothing to lose and a lot to gain.

This is also one of things that needs to be well optimized to be any useful. Army of agents may get an implementation, but not sure it will be actually useful, and I'm also not sure if optimizing that implementation is going to be easier than more well paced use of LLM where person actually understands what code is being generated.

You seem to contradict yourself. Army of agents doesn't mean the person doing that doesn't understand the code. And optimization is required no matter whether the bulk of the code is written by hand or by the machine. LLMs definitely make things actually doable where previously they were nearly impossible.

> Army of agents doesn't mean the person doing that doesn't understand the code

This is quite literally, objectively what it means lol. No human will ever seen it.

I'm not sure where you're getting the "objectively" from except from your self definition of what it means to let an AI agent work on a project.

A single agent can produce enough code that even a team human can't reasonably keep up with if properly reviewed. An army of agents, definitely not. Most of us this everyday at work. Some are ok with it some are not.

The way I see it, the people understand that software, somewhat similar to how most understand their cars - at a very high level -- there is wheel, steering, axles, engine, gas tank, you put petrol to run it etc etc. If it breaks down in middle of road, even with all the tools most wont likely figure out what's happening or fix the car, and eventually goto the mechanic.

Energy consumption and CO2 emission it causes is a pretty big lose

That CO2 will be emitted either way. We can choose though what % goes to funny cat videos and porn or useful open source code.

They build new data centers -> extra CO2

They build new power plants -> extra CO2

They built non-climate neutral power plants to power the data centers -> extra CO2

https://news.ycombinator.com/item?id=49223845

It’s not like we had some already produced spare energy lying around. Consumption went up, production went up, often it’s conventional production with CO2

There is a reason Google and MS scrapped their CO2 goals

This argument, while totally valid, will never halt the build out of data centers nor hamper the development of AI.

Run it with a self-hosted model on a gaming PC running off a solar panel and UPS.

Reply on news.ycombinator.com