Repository navigation
Compilation failure in DXC 1.10.2605.2 about invalid width i26 Integers #8421
Description
Description
I have a shader which compiles with DXC 1.9.2602 but fails with DXC 1.10.2605.2 (as tested on Godbot). The failures in 1.10.2605.2 are:
error: validation errors
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
error: Int type 'i26' has an invalid width.
Which, I don't create an 26-bit integers, so I don't know where the i26 comes from.
Steps to Reproduce
Compile the below with DXC with the flags -T ps_6_6 -E fs.
struct fs_outputs {
float4 tint_symbol : SV_Target0;
};
Texture2D<float4> tint_resource_table_array[] : register(t51, space43);
Texture2D tint_resource_table_array_1[] : register(t51, space45);
SamplerState tint_resource_table_array_2[] : register(s51, space46);
ByteAddressBuffer tint_resource_table_metadata : register(t52, space42);
float4 fs_inner() {
bool v = false;
if ((2u < tint_resource_table_metadata.Load(0u))) {
uint3 v_1 = uint3((tint_resource_table_metadata.Load(12u)).xxx);
v = any((v_1 == uint3(6u, 7u, 34u)));
} else {
v = false;
}
bool v_2 = v;
uint v_3 = 0u;
if (v_2) {
v_3 = tint_resource_table_metadata.Load(12u);
} else {
v_3 = 6u;
}
uint texture_kind = v_3;
uint v_4 = 0u;
if (v_2) {
v_4 = 2u;
} else {
v_4 = (0u + tint_resource_table_metadata.Load(0u));
}
uint v_5 = v_4;
bool v_6 = false;
if ((3u < tint_resource_table_metadata.Load(0u))) {
uint2 v_7 = uint2((tint_resource_table_metadata.Load(16u)).xx);
v_6 = any((v_7 == uint2(40u, 41u)));
} else {
v_6 = false;
}
bool v_8 = v_6;
uint v_9 = 0u;
if (v_8) {
v_9 = tint_resource_table_metadata.Load(16u);
} else {
v_9 = 41u;
}
uint sampler_kind = v_9;
uint v_10 = 0u;
if (v_8) {
v_10 = 3u;
} else {
v_10 = (4u + tint_resource_table_metadata.Load(0u));
}
uint v_11 = v_10;
bool v_12 = false;
if ((sampler_kind == 40u)) {
bool v_13 = false;
switch(texture_kind) {
default:
{
v_13 = false;
break;
}
case 1u:
case 6u:
case 11u:
case 16u:
case 21u:
case 26u:
{
v_13 = true;
break;
}
}
v_12 = v_13;
} else {
v_12 = true;
}
float4 v_14 = (0.0f).xxxx;
if (v_12) {
v_14 = tint_resource_table_array[v_5].Sample(tint_resource_table_array_2[v_11], (0.0f).xx);
} else {
uint v_15 = (4u + tint_resource_table_metadata.Load(0u));
v_14 = tint_resource_table_array[v_5].Sample(tint_resource_table_array_2[v_15], (0.0f).xx);
}
return v_14;
}
fs_outputs fs() {
fs_outputs v_16 = {fs_inner()};
return v_16;
}
Environment
- DXC version
- DXC 1.10.2605.2 fails
- DXC 1.9.2602 compiles
- Host Operating System
- Godbot
- Linux
Activity
dj2 commentedon May 5, 2026
dj2 commentedon May 5, 2026
Looks like this broke when the validation for integer sizes was enabled: 90ae8d8. It looks like the reason is the compiler is changing the size of the integer used in the switch:
dj2 commentedon May 5, 2026
Damyan Pepper (@damyanp)
damyanp commentedon May 11, 2026
dan sinclair (@dj2) - sorry for the delay, much of the team was travelling last week.
The "break" here is that the validator is detecting that invalid DXIL was being generated. So, we can work to fix the compiler to not generate invalid DXIL, but I'm interested to know if you've ever seen any runtime issues at all from presenting this shader to various GPUs?
Cameron187 commentedon May 12, 2026
I have a website with a WebGPU WGSL shader that was working without runtime issues in Chromium browsers on Windows until Chromium M148 picked up DXC 1.10.2605.2.
Then it started producing the error "GPUPipelineError: DXC compile failed with error: E_FAIL.".
The path in my case is WGSL > Tint > HLSL > DXC > DXIL inside Chromium's D3D12 backend.
The validation error in my case was "error: Int type 'i10' has an invalid width." (a different intermediate width).
I have a shader dump with the validation error that I can provide if that is helpful.
damyanp commentedon May 12, 2026
If it involves a switch statement then it's probably a dupe of this, otherwise please open a new issue. Thank you!
Cameron187 commentedon May 12, 2026
Yeah, big switch statement in my fragment shader. thanks.
dj2 commentedon May 12, 2026
I never got to trying the shader, I'm just creating the transform which created it. That said, it's just a switch statement over a set of numbers, so I don't see any reason why it wouldn't work.
damyanp commentedon May 12, 2026
The reason I'm asking is because DXC has always been generating invalid DXIL in this case, the recent change means that the validator now detects this and generates the error that you're seeing. I'm assuming that this is an existing shader that's worked previously? Or are the shaders hitting this newly written, and something about the new functionality in SM 6.10 that encourages these code patterns that we weren't seeing previously?
dj2 commentedon May 12, 2026
In my case, it was a shader I'm newly generating. But given this is any switch which just works on numbers, I'm sure there are folks who generate those shaders in the wild for WebGPU. There is nothing special about the switch, it's just a small set of integer values.
I was just trying to check if an integer was one of a set of values, but the way our WGSL compiler works, creating logical operations isn't available at the IR level so I created the equivalent switch statement.
If we can't generate a switch with integer values in the cases then we're going to have to change our WGSL generator for HLSL to not create switch statements at all.
[SimplifyCFG] Fix illegal-width bitmap from switch lookup table (#8444)