Bug 104119 - radv: OpBitFieldInsert produces 0 with a loop counter for Insert
Summary: radv: OpBitFieldInsert produces 0 with a loop counter for Insert
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/radeon (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-05 15:53 UTC by James Legg
Modified: 2017-12-07 09:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test application that reproduces the bug (5.28 KB, application/x-xz)
2017-12-05 15:53 UTC, James Legg
Details
SPIR-V disassembly of test shader (2.37 KB, text/plain)
2017-12-05 15:54 UTC, James Legg
Details
Output from RADV_DEBUG=shaders (3.93 KB, text/plain)
2017-12-05 15:54 UTC, James Legg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Legg 2017-12-05 15:53:05 UTC
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.
Comment 1 James Legg 2017-12-05 15:54:01 UTC
Created attachment 135981 [details]
SPIR-V disassembly of test shader
Comment 2 James Legg 2017-12-05 15:54:43 UTC
Created attachment 135982 [details]
Output from RADV_DEBUG=shaders
Comment 3 Samuel Pitoiset 2017-12-05 17:27:03 UTC
Something is wrong in the NIR.
Comment 4 Samuel Pitoiset 2017-12-05 17:34:07 UTC
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
 };
Comment 5 Samuel Pitoiset 2017-12-05 17:51:03 UTC
Patch is on the list.

https://patchwork.freedesktop.org/series/34930/
Comment 6 James Legg 2017-12-06 11:57:17 UTC
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.