Error during SPIR-V parsing of OpCopyLogical
System information
System:
Host: lupino2 Kernel: 6.2.0-36-generic arch: x86_64 bits: 64 compiler: N/A
Desktop: Fluxbox v: 1.3.5 dm: GDM3 Distro: Ubuntu 23.04 (Lunar Lobster)
CPU:
Info: 12-core model: AMD Ryzen 9 7900X bits: 64 type: MT MCP arch: Zen 4
rev: 2 cache: L1: 768 KiB L2: 12 MiB L3: 64 MiB
Speed (MHz): avg: 3453 high: 5495 min/max: 3000/5733 boost: enabled cores:
1: 2782 2: 4453 3: 3000 4: 3000 5: 2749 6: 3000 7: 3000 8: 5209 9: 2754
10: 3413 11: 4700 12: 2918 13: 3000 14: 4048 15: 5495 16: 3277 17: 2770
18: 2749 19: 2770 20: 4254 21: 3000 22: 4700 23: 3000 24: 2845
bogomips: 225594
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: AMD Navi 31 [Radeon RX 7900 XT/7900 XTX] vendor: ASUSTeK
driver: amdgpu v: kernel arch: RDNA-3 pcie: speed: 16 GT/s lanes: 16 ports:
active: HDMI-A-1 empty: DP-1,DP-2,DP-3 bus-ID: 03:00.0 chip-ID: 1002:744c
Device-2: AMD Raphael driver: amdgpu v: kernel arch: RDNA-2 pcie:
speed: 16 GT/s lanes: 16 ports: active: none empty: DP-4,HDMI-A-2
bus-ID: 13:00.0 chip-ID: 1002:164e temp: 41.0 C
Device-3: Valve 3D Camera type: USB driver: uvcvideo bus-ID: 8-2.1:3
chip-ID: 28de:2400
Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.8 driver: X:
loaded: modesetting alternate: fbdev,vesa dri: radeonsi gpu: amdgpu
display-ID: :0 screens: 1
Screen-1: 0 s-res: 2560x1440 s-dpi: 96
Monitor-1: HDMI-A-1 mapped: HDMI-1 model: HP X27q res: 2560x1440 dpi: 109
diag: 685mm (27")
API: OpenGL v: 4.6 Mesa 24.0.0-devel (git-ae17145882) renderer: AMD
Radeon RX 7900 XTX (radeonsi navi31 LLVM 15.0.7 DRM 3.49
6.2.0-36-generic) direct-render: Yes
Describe the issue
I ran into an assert/fatal error when compiling a SPIR-V shader that I believe should be valid - at least spirv-val doesn't complain and manual inspection seems like it's on the level. It works on NV/AMD drivers that I tested on windows as anecdata.
The SPIR-V file is here: debug_postts_after.spv
With a patch to spirv2nir I was able to compile it standalone and repro the same error. I'm not sure if there's a better way to specify capabilities on that tool (I didn't see one, but I'm unfamiliar):
$ git diff
diff --git a/src/compiler/spirv/spirv2nir.c b/src/compiler/spirv/spirv2nir.c
index 63635969b84..7a7f8fc74ac 100644
--- a/src/compiler/spirv/spirv2nir.c
+++ b/src/compiler/spirv/spirv2nir.c
@@ -295,6 +295,11 @@ int main(int argc, char **argv)
spirv_opts.caps.kernel = true;
}
+ spirv_opts.caps.int64 = true;
+ spirv_opts.caps.storage_8bit = true;
+ spirv_opts.caps.physical_storage_buffer_address = true;
+ spirv_opts.caps.mesh_shading = true;
+
nir_shader *nir = spirv_to_nir(map, word_count, NULL, 0,
entry_point.stage, entry_point.name,
&spirv_opts, &nir_opts);
$ ./dbuild/src/compiler/spirv/spirv2nir debug_postts_after.spv
SPIR-V parsing FAILED:
In file ../src/compiler/spirv/spirv_to_nir.c:369
Type mismatch for SPIR-V value %650
13988 bytes into the SPIR-V binary
Trace/breakpoint trap (core dumped)
$ spirv-val debug_postts_after.spv --target-env vulkan1.3 --scalar-block-layout
$ spirv-dis --no-color --raw-id debug_postts_after.spv | egrep '%(650|614|649|596|6|615|595|7) ='
%6 = OpTypeInt 32 0
%7 = OpConstant %6 64
%595 = OpTypeArray %6 %7
%596 = OpTypeStruct %6 %595
%615 = OpTypeArray %6 %7
%614 = OpTypeStruct %6 %615
%649 = OpLoad %596 %598 None
%650 = OpCopyLogical %614 %649
You can see I've grepped the relevant IDs out of the disassembly. %650 is a logical copy between two structs that are identically defined {int32_t, int32_t[64]}
but one of them has Offset
decorations (omitted here as it shouldn't be relevant). The compiler assert seems to be expecting the types to be exactly identical, but the SPIR-V spec says for OpCopyLogical:
Result Type must not equal the type of Operand (see OpCopyObject), but Result Type must logically match the Operand type.
And 'logically match' is defined as basically recursively having equivalent types, minus decorations.
If I comment out the error check in vtn_push_ssa_value
it does compile the shader, but I see corruption/misbehaviour past that point so I don't know that it's just an overly-stringent check failing.
Log files as attachment
The error backtrace is here: backtrace.txt
Any extra information would be greatly appreciated
This shader was generated from RenderDoc's mesh shader support that I just pushed to public v1.x. When capturing from niagara if the mesh viewer is open when selecting the first mesh draw, this shader is generated as a result of patching the task shader to output its data to a BufferDeviceAddress buffer, for the first step of fetching mesh outputs.