Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.

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:

  1. Quake 2 RTX (Vulkan): works. This was working already on my previous update.
  2. Control (D3D): works. Pretty much just works. Runs at maybe 30-50% of RT performance on Windows.
  3. 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.
  4. 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.
  5. 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.
30 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
8 comments

Zappor Sep 17, 2021
That's not really correct... They have ray tracing support with AMDGPU Pro, on Ubuntu 20.04.

But yeah, nobody uses that 😁
MaximB Sep 17, 2021
So how does Metro Exodus and Doom Eternal run on Stadia? without Ray Tracing?
chomwitt Sep 17, 2021
When we say we run Control (D3D) i guess we mean in Wine with a D3D linux port , right?
Liam Dawe Sep 17, 2021
Quoting: chomwittWhen 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.
chomwitt Sep 17, 2021
Isn't Proton a patched wine?
Leopard Sep 17, 2021
Quoting: chomwittIsn'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
Quoting: Leopard
Quoting: chomwittIsn't Proton a patched wine?

Yes but where did you pull that "port" part?

No one ports anything, Wine/Proton usage =! Port
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.
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...
a0kami Sep 18, 2021
Quoting: slaapliedjeI 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
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.