Black screen upon using any builds other than release 1.6.0

[Connor-GH]

After launching the game and turning on RTX, I am met with a black screen everywhere besides the HUD. The opengl renderer works perfectly find, however. Building Q2RTX myself, as well as using github artifacts, produces this behavior:

opengl runs fine, as seen here:

hardware:
ryzen 7 5700G (APU disabled)
radeon rx 6600 (RADV and AMDGPU)

software:
OS: Gentoo Linux 5.15.80 kernel
Display server: wayland (running sway, which is wlroots)
CC: gcc-11
CXX: g++-11

to clarify: this behavior is not caused by an XWayland or Wayland bug, as the 1.6.0 release works fine. SDL_VIDEODRIVER=wayland starts the game, but doesn't create a window, anyways.

[res2k]

This is probably related to the raytracing support in the driver(s). Something Q2RTX does the driver(s) don't like. Could be either one's "fault" (ie, maybe Q2RTX does something that's not correctly supported, or something that is technically incorrect but it gets away with it on NV drivers). Since 1.6.0 apparently works fine you could try bisecting to the first "broken" commit. This can give some insight into the issue. More generally, you could research to what extent RADV supports Q2RTX (eg by searching in mailing lists). Perhaps also try a newer version, I think RT support is still actively worked on.

…

On Wed, 21 Dec 2022, 18:33 Connor-GH, ***@***.***> wrote: After launching the game and turning on RTX, I am met with a black screen everywhere besides the HUD. The opengl renderer works perfectly find, however. Building Q2RTX myself, as well as using github artifacts, produces this behavior: [image: 2022-12-21-1120AM] <https://user-images.githubusercontent.com/72793802/208967275-abdd0845-3010-4833-8f82-04550973942a.png> opengl runs fine, as seen here: [image: 2022-12-21-1122AM] <https://user-images.githubusercontent.com/72793802/208967346-05f6c879-be61-4541-adec-63f02f43f2f2.png> hardware: ryzen 7 5700G (APU disabled) radeon rx 6600 (RADV and AMDGPU) software: OS: Gentoo Linux 5.15.80 kernel Display server: wayland (running sway, which is wlroots) CC: gcc-11 CXX: g++-11 to clarify: this behavior is not caused by an XWayland or Wayland bug, as the 1.6.0 release works fine. SDL_VIDEODRIVER=wayland starts the game, but doesn't create a window, anyways. — Reply to this email directly, view it on GitHub <#251>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7NIAUS4B55JHFC4KREJHTWOM5QJANCNFSM6AAAAAATF3WZQU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[res2k]

Actually, please also include the installed driver/Mesa versions in the report, it's relevant information.

…

On Wed, 21 Dec 2022, 18:33 Connor-GH, ***@***.***> wrote: After launching the game and turning on RTX, I am met with a black screen everywhere besides the HUD. The opengl renderer works perfectly find, however. Building Q2RTX myself, as well as using github artifacts, produces this behavior: [image: 2022-12-21-1120AM] <https://user-images.githubusercontent.com/72793802/208967275-abdd0845-3010-4833-8f82-04550973942a.png> opengl runs fine, as seen here: [image: 2022-12-21-1122AM] <https://user-images.githubusercontent.com/72793802/208967346-05f6c879-be61-4541-adec-63f02f43f2f2.png> hardware: ryzen 7 5700G (APU disabled) radeon rx 6600 (RADV and AMDGPU) software: OS: Gentoo Linux 5.15.80 kernel Display server: wayland (running sway, which is wlroots) CC: gcc-11 CXX: g++-11 to clarify: this behavior is not caused by an XWayland or Wayland bug, as the 1.6.0 release works fine. SDL_VIDEODRIVER=wayland starts the game, but doesn't create a window, anyways. — Reply to this email directly, view it on GitHub <#251>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7NIAUS4B55JHFC4KREJHTWOM5QJANCNFSM6AAAAAATF3WZQU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Connor-GH]

Mesa 22.2.3 (Newest).
I have the following drivers installed: RADV, AMDGPU, and RadeonSI.

Q2RTX tag v1.6.0 builds fine (after a minor patch to extern/zlib/{example,minizip).c and extern/SDL/src/video/wayland/SDL_waylandy.h, which i can add in my open PR if wanted; It helps with some linking and compile errors on Gentoo to make it build.)

anyways:

 git bisect good ce54f51a443f038a5d2a0a6f061acae5d3adc42c                                 git@(no branch, bisect started on 701cf318)
6b47fa4752b8e31fe4df4f1684a88ba6487fa77e is the first bad commit
commit 6b47fa4752b8e31fe4df4f1684a88ba6487fa77e
Author: Frank Richter <[email protected]>
Date:   Sun Feb 27 16:10:09 2022 +0100

    Make particle brightness configurable

 src/refresh/vkpt/shader/global_ubo.h              | 1 +
 src/refresh/vkpt/shader/path_tracer_hit_shaders.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

[Connor-GH]

Interestingly,

Q2RTX/src/refresh/vkpt/shader/global_ubo.h

Line 93 in 6b47fa4

UBO_CVAR_DO(pt_particle_brightness, 500) /* particle brightness */ \

is the exact line that breaks this. Hardcoding the color.rgb value to 500 in path_tracer_hit_shaders.h, therefore not interacting with the global_ubo variable at all, results in the observed "bad" result.

Moving This line to the bottom of the UBO_CVAR_DO list solves this issue (Line 126).

Although, we should figure out why this was the problem.

[Connor-GH]

Now it seems after I clone the master branch at its current commit and apply my patches, I get the black screen effect again. there was another change to global_ubo in this time though, which could be something to look into.

[res2k]

Hm, can you try removing/renaming shaders.pkz so it's contents aren't used?
This should make sure Q2RTX uses the shader .spv files generated by the build.
("Mismatching" shaders may explain why shuffling things around in the UBO fixes the issue.)

[Connor-GH]

At no point was shaders.pkz used. I didn't zip the shaders and so they've been runnning out of shaders_vkpt/.

EDIT: Moving pt_particle_brightness, pt_direct_dyn_lights, and pt_indirect_dyn_lights to the bottom of the UBO_CVAR_DO list "fixes" this issue. Something about changing shader names and adding more seems to be the issue here...

[res2k]

FWIW, I was thinking about the shaders.pkz from the Q2RTX data, eg as found in the Steam files.
Those additional data files are needed, otherwise Q2RTX won't work; so I was thinking that maybe a shaders.pkz is present there and the shaders are used from there.

(FYI, the used archives are listed upon start up, or with the path console command.)

[Connor-GH]

Ah, right.

Current search path:
$USER/.local/share/quake2rtx/baseq2
$USER/.local/share/quake2rtx/baseq2/q2rtx_media.pkz (4054 files)
$USER/.local/share/quake2rtx/baseq2/blue_noise.pkz (258 files)
$USER/.local/share/quake2rtx/baseq2/pak3.pak (8 files)
$USER/.local/share/quake2rtx/baseq2/pak2.pak (2 files)
$USER/.local/share/quake2rtx/baseq2/pak1.pak (279 files)
$USER/.local/share/quake2rtx/baseq2/pak0.pak (3307 files)
$USER/Downloads/Q2RTX/baseq2

(this build I am using is the same as the master, except that it has the pseudo-XDG patch and the few patches to make the game compile; none of these changes would affect shader performance.)

[res2k]

At no point was shaders.pkz used. I didn't zip the shaders and so they've been runnning out of shaders_vkpt/.

EDIT: Moving pt_particle_brightness, pt_direct_dyn_lights, and pt_indirect_dyn_lights to the bottom of the UBO_CVAR_DO list "fixes" this issue. Something about changing shader names and adding more seems to be the issue here...

Hm, the names shouldn't matter here, this is all compiled into "offsets into buffers".
But of course changing the order of the UBO entries changes those offsets, and they mismatching between compiled C++ and shader code could very well cause your issues.
Similar with the number of entries, as this will affect the size of the buffer. (Although it's padded to some "UBO alignment" value which is Vulkan implementation dependent.)

Seems to be quite the odd issue.

[Connor-GH]

The change from direct_sphere_lights to direct_dyn_lights was also a breaking change. This does seem like a shader mismatch issue, since it is in the same spot, but has a different name. I conceptualize this similar to when a linker cannot find a symbol, or the symbol has a different return type or arg type. Would this be a somewhat accurate depiction?

[res2k]

Hm. The name shouldn't matter...
What happens is that the the stuff in global_ubo.h is used to generate two structs, one for C, one for GLSL. (Check the use of #ifndef VKPT_SHADER.) Both structs should have the same memory layout. With that, anything that is written on the C side to a buffer should be identically interpreted on the GLSL side.
So the actual names don't play into that here, they are not used at runtime at all. It's just the offset for each member that matters. (That the identifiers are the same in C and GLSL is certainly convenient but not necessary for things to work.)