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.
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.
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.
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.
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.
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.
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.
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
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.
Also covered here: https://www.phoronix.com/news/Triton-DirectX-11-QEMU-Driver
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.
There's that small thing of DirectX 12 predating Vulkan (and massively predating the useful Vulkan specs).
DX12 is much more complex to implement. Very different API.
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.
Energy consumption and CO2 emission it causes is a pretty big lose
This argument, while totally valid, will never halt the build out of data centers nor hamper the development of AI.