Denoiser hallucinates incorrect position of first person model

[kd-11]

I observed this when implementing AMD support. Strangely, it only happens in specific maps, so it is likely related to the map size. Initially I thought the sreen wipe effect was somehow messing with the motion vectors but this is incorrect. It happens on specific maps and is persistent. The most obvious case is E1M2 and E4M2 in DOOM1. Here is a screenshot where I rapidly strafe right then immediately start strafing left. You can see the hallucinated first-person model to the right which is the incorrect position. It is persistent, with the fake hand always at the wrong position while in the map. The muzzle flash sprite also shows up at this incorrect position.

Image:

Research notes:

• This is caused by the denoiser. Bypassing it hides the issue.
• This is not a barrier issue, I hacked the barrier code to inject full barriers for every framebuffer before every operation and the error is still there.
• GPU load seems to have some impact on this, which is why I suspect the BVH has some influence on how serious it becomes. I need to check how the position and motion vectors are encoded to verify this. For example, when doing a full desktop recording, the bug is almost completely hidden.
• When going out of bounds with the idclip cheat, you can see a duplicate first person view at the correct position, just dimmed out. I did not get a screenshot of this, but it seems like at least the current position is correct, but the accumulated temporal resolve is not.
• This problem is visible somewhat on NV cards but it is not very pronounced. It is just that the glitch is exaggerated a lot on AMD hardware.

I captured some footage of it on E1M2, but the glitch is well hidden as the GPU load hides the issue. https://youtu.be/UPYsaqxvPVs The bug is observable the moment I load into E1M2 if you watch the shotgun sprite closely. It is more noticeable at 1:47-1:48 during the shotgun's reload animation frames.

I'll keep checking, but I don't have much free time to investigate so I figured I may as well have this documented somewhere. Incidentally the video also shows a crash (DEVICE_LOST) that is 100% reproducible at the end. Build used requires https://github.com/sultim-t/RayTracedGL1/pull/11

[kd-11]

Update: I verified it is a problem with the motion vectors. There is an imprint of the player model that remains temporally stable with a motion value close to 0 giving it temporal lag on the screen. The results are rather comical on some levels, but it is actually not too bad on most. I'll check it again in a few days if I find some time.

[sultim-t]

That's good to hear :)

For the rapid shader development, I open Shaders folder in VS Code with ScriptRunner extension with such settings in its json file:

"script-runner.statusBar" : false, "script-runner.definitions": { "commands": [ { "identifier": "shaderBuild", "description": "Build shaders", "command": "cls; python .\GenerateShaders.py -ps", "working_directory": "${workspaceFolder}", }, { "identifier": "shaderGenAndBuild", "description": "Build shaders with generating common files", "command": "cls; python .\GenerateShaders.py -ps -g", "working_directory": "${workspaceFolder}", } ], },

Then I bind hotkeys to shaderBuild and shaderGenAndBuild (full rebuild) to easily compile them.

In PrBoom there's a "-rtdevmode" cmd argument, so PageUp button can be used to hot-reload shaders.

[kd-11]

Thanks! That is very handy.

[urielejh]

I'd like to leave some feedback - if needed - for the AMD implementation. Where can i do it? The page of the build where the download link and the changelog are is locked..

[ColinSalem]

I'd like to leave some feedback - if needed - for the AMD implementation. Where can i do it? The page of the build where the download link and the changelog are is locked..

You could probably just leave it here if it's related to the specific issue mentioned in this post, otherwise you could raise a new issue.

[kd-11]

I'll spare a few hours today to look into this one.

[kd-11]

The fix along with an explanation of the problem can be found in this PR: https://github.com/sultim-t/RayTracedGL1/pull/14 If you have an AMD GPU and can build from source, please test and give feedback.

[jp-bennett]

If you have an AMD GPU and can build from source, please test and give feedback.

Fedora 35, Bleeding edge Mesa, and a Radeon 6700 XT. The player's hand/weapon no longer disconnects from location when strafing. There are still some visual artifacts left, but not sure it's related to this problem. See: https://www.youtube.com/watch?v=mV-KMCf7Q3s

[kd-11]

That bug is not present on windows, the experience is practically flawless with the proprietary drivers. While I do use linux as a daily driver, I have not really checked it on the platform as vulkan RT support is still incomplete on mesa/RADV. It does look to be an issue with the any hit shader, there is a alpha test done to determine whether to terminate the ray or to continue searching and it seems not to be working for you. I'll likely poke at it some time in the future. For now, I'll close this issue as resolved.

[jp-bennett]

the experience is practically flawless with the proprietary drivers.

Should I open an issue in the Mesa repo? How likely do you think it's a Mesa issue, vs application?

[kd-11]

You can open one with mesa. While I can investigate the issue, it would take a long time as I can only really look at this on weekends.

[jp-bennett]

@kd-11 Mesa issue opened here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6348

[jp-bennett]

@kd-11 Update, I've tested with AMDGPU-PRO, and the transparencies are rendering correctly there. So seems to be a Mesa bug.