While Ray Tracing has worked on Linux for a long time with NVIDIA, the situation with Mesa+AMD is still being worked out but the good news is that it's all finally coming together.
Developer Bas Nieuwenhuizen wrote in a new blog post about the current situation noting that after over 9 months of work, that they're now seeing games working. Control was one title shown off that worked "on first try" once the required bits were hooked up in the radv Mesa driver.
Nieuwenhuizen mentioned these games tested:
- Quake 2 RTX (Vulkan): works. This was working already on my previous update.
- Control (D3D): works. Pretty much just works. Runs at maybe 30-50% of RT performance on Windows.
- Metro Exodus (Vulkan): works. Needs one workaround and is very finicky in WSI but otherwise works fine. Runs at 20-25% of RT performance on Windows.
- Ghostrunner (D3D): Does not work. This really needs per shadergroup compilation instead of just mashing all the shaders together as I get shaders now with 1 million NIR instructions, which is a pain to debug.
- Doom Eternal (Vulkan): Does not work. The raytracing option in the menu stays grayed out and at this point I’m at a loss what is required to make the game allow enabling RT.
Not quite there yet with more work to be done. Nieuwenhuizen still needs to upstream the code to the official Mesa repositories, work is needed to improve "the pipeline compilation model to hopefully make ghostrunner work", work on performance with improved "BVH building", improve traversal and then also move onto bits needed for DXR 1.1 including VK_KHR_ray_query.
So it's all getting there. Hopefully by the end of the year we might see properly working AMD Ray Tracing on Linux.
Article taken from GamingOnLinux.com.
But yeah, nobody uses that 😁
When we say we run Control (D3D) i guess we mean in Wine with a D3D linux port , right?It means the Windows version played with Proton.
Isn't Proton a patched wine?
Yes but where did you pull that "port" part?
No one ports anything, Wine/Proton usage =! Port
slaapliedje Sep 17, 2021
It is kind of weird how that fine line gets manipulated. Like the VP 'ports' sort of appear to look like native games. But they were created with a wrapper (called Eon if I recall correctly) which uses Wine to get things to work.Isn't Proton a patched wine?
Yes but where did you pull that "port" part?
No one ports anything, Wine/Proton usage =! Port
I think some of the Feral / Aspyr ports were done in a similar way? (I can't recall who said that, but someone did at somepoint and I was never sure it was correct.)
Back on topic, nice to see progress on the AMD front! Would be wonderful if we could purchase hardware...
I think some of the Feral / Aspyr ports were done in a similar way? (I can't recall who said that, but someone did at somepoint and I was never sure it was correct.)
Feral has in-house tools, they make sure they stay as far away as they can possibly get from wine and other translation layers because they don't want (or can't afford) to enter any licence legal issue, regardless how permissive licences such as MIT are.
They basically have working implementations of a "DirectX back end" specifically targeted for Vulkan (Linux), Metal (iOS and macOS) and OpenGL (was used at some point macOS, mobiles and Linux). Engines from the games they port basically use the native "DirectX front end", which API calls are hooked to their own DX backend libraries during compile time, so they make minimal changes to the original graphics pipeline of the game and they keep high performance.
No idea how Aspyr are doing their thing though.
But yeah theoretically both companies could use any combination of translation layer and contribute to the effort but meh. (DXVK can also be used in a standalone way as if you'd have a DirectX game sources, you could just throw in DXVK and compile for a Linux platform without porting the graphics part, provided you figured a way out of msvc and external dependences.)
Last edited by a0kami on 18 September 2021 at 1:17 am UTC
Patreon
PayPal
See more from me