The main use case of this is in porting. So if someone wanted to make a native port of their game, this library would make it potentially much easier.
That post seems to be missing.
angrymouse 15 points 3 years ago
Both use wine iirc, Op is talking about applications written directly for Linux.
Edit: im wrong
odc 70 points 3 years ago
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.
A_Porcupine 24 points 3 years ago
Here's the roadmap: https://github.com/...
TL;DR: they're targeting DX9 initially, later expanding to include DX12.
AlmightySnoo 47 points 3 years ago
That repo is just pure trolling, read the "Improved performance" section and open some source files and you'll understand why.
themoonisacheese 46 points 3 years ago
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.
azvasKvklenko 22 points 3 years ago
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.
AMDIsOurLord 29 points 3 years ago
OpenGL is actually older. Microsoft just spent a lot of time and money on DX adoption.
Overall, it's the native API of Windows and that has the largest user base. On the other hand, many non-game professional apps use OpenGL/Vulkan
velox_vulnus 8 points 3 years ago path: 0 6203873 6204095, hotness: undefined, score: 8, children: 12
velox_vulnus 10 points 3 years ago path: 0 6203873 6204095 6204102 6206434, hotness: undefined, score: 10, children: 1
KingThrillgore 5 points 3 years ago
It takes 75 lines to draw a blank window. It takes like three in CoreAnimation in macOS. We really need an OSS take on CoreAnimation but I'm also fine leaving the graphics work to a game engine.
Ansis 8 points 3 years ago
Lower level means you have more control over the small details. However, that also means that you have to reimplement some things from scratch, while higher level frameworks do those things for you.
heartsofwar 1 point 3 years ago path: 0 6203873 6204095 6204102 6204813 6208263, hotness: undefined, score: 1, children: 5
Chobbes 4 points 3 years ago
There’s a few Linux “native” releases on steam that use compatibility layers based on wine behind the scenes, which I think is probably what they mean.
Also, this feels wrong, but… Is wine native? It’s mostly just the windows api implemented as Linux libraries. What’s the distinction that makes it “non-native” compared to other libraries? Is SDL non-native too?
teawrecks 1 point 3 years ago
"Native" means "no platform specific runtime translation layers". An app built on SDL does the translation to the final rendering API calls at compile time. But a DX app running on Linux has to do jit translation to ogl/vk when running through wine, which is just overhead.
Chobbes 1 point 3 years ago
My understanding is that DXVK implements the Direct3D API using vulkan behind the scenes. So, sure, there might be a bit of overhead versus a more direct implementation. Frankly this doesn’t feel all that different from something like SDL to me. Shaders will have to be compiled into shaders that Vulcan understands, but you could just think of this as part of the front end for shader compilation.
I do agree that it feels less native to me too (particularly over the rest of wine), but it’s sort of an arbitrary distinction.
manito_manopla 11 points 3 years ago
How is this different from DXVK?
FehrIsFair 24 points 3 years ago
It's made to interact directly with the GPU instead of translating it to the equivalent GPU call in Vulkan.
hare_ware 11 points 3 years ago
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?
leopold 3 points 3 years ago
Afaik the only way to avoid translating into OpenGL and Vulkan would be to write native drivers. Stuff like gallium-nine, for instance. Is that what this project is doing? Though obviously that's just for the Direct3D side of things and there's a lot more to DirectX than just that. Still, it's hard not to question how much of this is just duplicating work already done for Wine.
carl_the_grackle 9 points 3 years ago
Excited to see how this plays out. Looks like there's basically nothing implemented yet though.
WeLoveCastingSpellz 6 points 3 years ago
Holly Fuck!
drasticpotatoes 2 points 3 years ago path: 0 6204484 6210880 6211252, hotness: undefined, score: 2, children: 0
library_napper 6 points 3 years ago
One of these days I'll be able to play quake in QubesOS
viking 3 points 3 years ago
Is anyone still playing Xonotic? I used to play Nexuiz back before they sold the name, and tried Xonotic recently, only to find servers with maximum one other player idling around. I genuinely thought it's dead.
uis 1 point 3 years ago
I know 4 major servers: Feris and 3 Jeff's. Feris is most populated one during European night. And there are pickup servers that usually play 4v4. Also smaller servers exist that occasionally get players like xonotic-relax.ru.
library_napper 1 point 3 years ago
Doesn't work in Qubes
CabbageColonialist 1 point 3 years ago
I use Qubes btw. But you wouldnt even know.
vexikron 3 points 3 years ago
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?
UnfortunateShort 5 points 3 years ago
So... What's the advantage compared to Wine? It's hard to imagine people will start developing for DX on Linux instead of going for Vulkan, and that DX alone is enough to run a lot of games for Windows. Or am I completely off here?
warmaster 8 points 3 years ago
Now that Proton is mature, devs generally benefit of getting two platforms while targeting only one.
I don't see many devs going for Vulkan and native ports, so a DirectX on Linux port has even less chances. On top of that, Khronos has the backing of several tech giants, this DX on Linux project is built by 2 random guys with no support whatsoever.
MajorHavoc 4 points 3 years ago
I'm guessing, but I bet old games built for DirectX (almost every game made between 1995 and 2005) will run a lot better on Linux with 1:1 DirectX support.
Probably more exciting to retrogamers then anyone else.
cyberpunk007 1 point 3 years ago
Do games no longer use directx?
MajorHavoc 1 point 3 years ago
I'm pretty sure DirectX is still in use, but it used to be 95% of all games needed it and also crashed with a "you need to configure DirectX exactly and only the way this game demands". That seems to have calmed down, at least.
ifGoingToCrashDont 3 points 3 years ago
It's right in the description
This is a Open Source DirectX implementation for Linux, providing native support for DirectX-based applications and games, without relying on Wine's Windows compatibility layer.
UnfortunateShort 1 point 3 years ago
Yeah, but in some cases you already achieve better-than-native performance in wine and you don't need Wine just for DX. You would most likely need to explicitly support Linux in addition to Windows, even if Linux could handle DX.
I assume you can expect some performance benefit if you were to integrate this into Wine, but I kinda doubt it will gain too much traction outside of that. Vulkan already exists as a well supported, cross-platform solution and engines are already using it.
neatchee 1 point 3 years ago
This appears to be about reducing complexity and surface area for failure in running DirectX games
Any time you are translating function calls from one interface to another there is more opportunity for mistakes and incompatibilities. If you are implementing the DX functions directly to make the expected hardware calls directly, just as they're implemented in Windows, you are less likely to have unexpected behavior when combining everything.
Think of it like a language translator. It's the difference between translating between two languages or between three. If you write something that is intended to be translated from English to Mandarin by Mitch Microsoft, but Mitch isn't available, so you need to have Larry Linux translate it, which would you rather: translate it from English to Greek, then Greek to Mandarin, or directly from English to Mandarin?
thanks for using Leebra!
go to feed...
I don't think there would be any real benefit to this over DXVK and VKD3D
save