search

sultim-t / RayTracedGL1

MIT License
128 stars 29 forks source link

AMD GPU support #11

Closed kd-11 closed 2 years ago

kd-11 commented 2 years ago

This PR contains the following fixes for AMD RDNA2:

Results: image

Known issues:

Tested with DOOM1 full game iwad.

kd-11 commented 2 years ago

For the record, I noticed in the DF video some similar smearing, but in this case I do not have DLSS enabled, so it could be a legit bug with the code and not something specific to AMD. I do not have access to a RT-capable NV GPU to verify this claim. The crashing does not happen if the arm glitch is not present. I've left it running for over half an hour after loading directly into a level with no issues, so there is certainly a correlation.

sultim-t commented 2 years ago

This is mindblowingly cool! :D I will make a pre-release build for PrBoom, so people can at least try it to run

ColinSalem commented 2 years ago

Known issues: Random crashing, though I'm unsure if it has anything to do with the executable or not. There is a spec violation about maxRecursion value (2) in shaders being higher than the AMD setting which is 1, but fixing this has no impact on stability. The player's hand gets smeary after transitioning between levels. This seems to be the cause of the crashing. The glitch resembles messed up motion vectors when implementing TAA, but I haven't checked any further. Booting directly into any level seems to work fine.

In my experience, booting directly into levels (via the -warp command line param) does not fix this. Oddly enough, booting directly into the first map of an episode works fine - it's just when I try to boot to any map that isn't the first that the game crashes after getting some sort of visual glitch.

kd-11 commented 2 years ago

@NO0bMaster69 See research at https://github.com/sultim-t/prboom-plus-rt/issues/38 I won't have time to look at it for a few days but I did all the tests warping around with idclev. At first it seems the map number affects the result, but looking at the source code shows it is likely a coincidence.

ColinSalem commented 2 years ago

@NO0bMaster69 See research at https://github.com/sultim-t/prboom-plus-rt/issues/38 I won't have time to look at it for a few days but I did all the tests warping around with idclev. At first it seems the map number affects the result, but looking at the source code shows it is likely a coincidence.

Ah, I see. On testing this myself the only other maps I could get to work were E2M8 and E3M8. In case if this is of any use to you, on my end the crashing seems to be primarily caused by opening doors, pressing switches, and shooting (punching does not cause it to crash); if I just run through the level without doing any of the aforementioned actions it'll run like normal aside from the visual glitches.

DwarfFighterCleric commented 2 years ago

I'm a bit confused. Has anyone managed to get this running on Ryzen 3000 chips? I have a Ryzen 3500U (Vega 8 - laptop) and I'm getting that error message "Can't Find Physical Device"... So is my GPU permanently uncapable of Ray Tracing at all? Or is it something that I can activate with Driver Updates? But I'm confused because I already have 2022 driver... not sure what is going on

DwarfFighterCleric commented 2 years ago

This is the part that is confusing: official statements from AMD say that offer support for Ray Tracing in 3000 generation chips, but then from what I've seen the Vulkan API itself does not support Vega 8, only supports Vega 10. So am I doomed to not enjoy this because of Vulkan? I'm trying to understand what's going on, it seems like I am so close to actually running this...

kd-11 commented 2 years ago

Vega does not support raytracing at all. You need at least rdna2 for hardware RT

megatog615 commented 2 years ago

On Linux you can enable RT on older chips with RADV_PERFTEST=rt (this is heading to mesa as default in some capacity soon)