| Summary: | radv: OpBitFieldInsert produces 0 with a loop counter for Insert | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | James Legg <jlegg> |
| Component: | Drivers/Vulkan/radeon | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
test application that reproduces the bug
SPIR-V disassembly of test shader Output from RADV_DEBUG=shaders |
||
Created attachment 135981 [details]
SPIR-V disassembly of test shader
Created attachment 135982 [details]
Output from RADV_DEBUG=shaders
Something is wrong in the NIR. Possible fix:
diff --git i/src/amd/vulkan/radv_shader.c w/src/amd/vulkan/radv_shader.c
index 4a3fdfa80e..0b19d23fa2 100644
--- i/src/amd/vulkan/radv_shader.c
+++ w/src/amd/vulkan/radv_shader.c
@@ -66,6 +66,7 @@ static const struct nir_shader_compiler_options nir_options = {
.lower_extract_byte = true,
.lower_extract_word = true,
.lower_ffma = true,
+ .lower_bitfield_insert = true,
.max_unroll_iterations = 32
};
Patch is on the list. https://patchwork.freedesktop.org/series/34930/ I've submitted another patch that fixes the constant folding that was going wrong: https://patchwork.freedesktop.org/patch/191977/ |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 135980 [details] test application that reproduces the bug On RADV, the SPIR-V OpBitFieldInsert opcode produces 0 when the Insert parameter derives from a variable used as a loop counter. For example, the following GLSL compute shader writes 0 to the first 8 elements of the buffer at binding 0: #version 450 core layout(local_size_x = 1, local_size_y = 1, local_size_z = 1) in; layout (std430, set = 0, binding = 0) restrict writeonly buffer u2_cs { uint u2[]; }; void main() { for (int i = 0; i < 8; i++) u2[i] = bitfieldInsert(0, i, 16, 2); } I've attached a program that reproduces the bug. I'm using the LLVM release_50 branch at revision 318947 and the Mesa master branch at 20d37da597653201d2c524434907e817bd03b1d0.