Oooo shit that is right up my ally!
*alley
(Unless they have installed it onto their ASUS ROG Ally of course.)
Aha, oops!
Midnight posting on mobile makes one prone to spelling errors.
For what its worth my preference with hand held devices remains as the Steam Deck =P
I guess you could say I am an ally of the Ally?
Why do I get the feeling it will have the same development roadblocks as ReactOS?
Why is this not being developed inside Mesa? There’s even precedent for it; gallium9.
Because DirectX apps typically do not only call into DirectX but also the win32 API, since DirectX has historically been a windows-only API. Merging this into mesa would only bloat mesa while not really offering support for many applications at all.
This is a great project in general, but it’s quite overshadowed by DXVK which does the same except it translates DX calls to vulkan ones and has excellent success rates in proton and derivatives. I guess this is mildly useful for systems that don’t support vulkan but want to run DX apps in raw wine or simply for people who wish not to use DXVK - competition is good for the ecosystem.
Merging this into mesa would only bloat mesa while not really offering support for many applications at all.
But there already is a d3d9 driver inside mesa?
Could be big. Love wine but even games with native release for Linux have wine reliance
This seems incorrect, if it’s running natively, it doesn’t need to rely on wine…
Holly Fuck!
Poor Holly
Tis the season (for holly).
The README does not say which DirectX version they are targeting. The screenshot show “DirectX 0”. Looking at the code, I see a directory called “d3d9”, but those files are mostly empty.
So yeah… nothing to see here. Maybe in 5 or 10 years.
Too late, I already hyped it on Mastodon.
But yeah, seems like a glimmer in the postman’s eyes at the moment.
And the bit saying DxDiag opens faster feels really strange…
How would a native implementation be better than DXVK? Wouldn’t develops still need to port the rest of their app to Linux to use it? At that point, you could still just include DXVK, would the performance really be that much worse?
How is this different from DXVK?
Iirc, DXVK translates DirectX API calls to Vulkan calls, meaning the original game renders to Vulkan in the end. With this, no translation will be needed which should result in slightly better performance and more likely, much better compatibility.
IIRC the translation overhead is usually negligible and sometimes results in better performance due to Vulkan being very performant.
One of these days I’ll be able to play quake in QubesOS
This is barely explained and the readme gave me more questions than answers.
I immediately thought it’s going to be a library for Wine to use instead of DXVK/VKD3D.
If that’s only for developers to build Linux ports, very little to no real-world use is expected, unless it’s somehow can offer effortless conversions. Even then developers are likely to prefer relying on Proton/Wine to simply have single binary for both platforms, rather than maintaining them separately.
I wonder how much work it will take for drivers to support the API… Or maybe it won’t need anything in Mesa and will somehow work directly on DRM with strictly platform-agnostic code if that’s possible?
Offering better performance than the likes of DXVK is brave to put it mildly. In many scenarios it can already match or surpass native Windows performance even when running Windows binaries.
This is barely explained and the readme gave me more questions than answers.
make a pull request to change the readme then
Noob here, but can someone explain to me what’s the advantage of DirectX vs Vulkan, apart from being around for longer? And why do more developers embrace Vulkan for better portability?
