Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPIR-V] Casting 16bit integral data types #6319

Open
ChristianReinbold opened this issue Feb 16, 2024 · 1 comment · May be fixed by KhronosGroup/SPIRV-Tools#5590
Open

[SPIR-V] Casting 16bit integral data types #6319

ChristianReinbold opened this issue Feb 16, 2024 · 1 comment · May be fixed by KhronosGroup/SPIRV-Tools#5590
Assignees
Labels
bug Bug, regression, crash spirv Work related to SPIR-V

Comments

@ChristianReinbold
Copy link
Contributor

Description

DXC generates invalid spir-v code when casting 16bit data types.

Steps to Reproduce

https://godbolt.org/z/5vKcqxT76

Compile the following shader with options -T lib_6_4 -spirv -fspv-target-env=vulkan1.2 -enable-16bit-types -HV 2021

[[vk::binding(0,4)]] RWStructuredBuffer<uint16_t> a;

[shader("raygeneration")]
void main() {
    int16_t v = -1;
    uint16_t vu = uint16_t(v);
    a[0] = vu;
}

Actual Behavior
Shader compilation fails with

fatal error: generated SPIR-V is invalid: The high-order bits of a literal number in instruction 15 must be 0 for a floating-point type, or 0 for an integer type with Signedness of 0, or sign extended when Signedness is 1
%ushort_4294967295 = OpConstant %ushort 4294967295

Note that both

void main() {
    uint16_t vu = uint16_t(-1);
    a[0] = vu;
}

and

void main() {
    uint16_t vu = uint16_t(int16_t(-1));
    a[0] = vu;
}

results in compiling to the expected result of storing an ushort constant of 65535 (2^16-1) to a[0], as would happen with a regular underflow. Also note that the generated constant in spir-v resembles 2^32 - 1. It seems like the underflow is incorrectly handled with 32bit precision instead of 16bit precision.

Environment

  • DXC version: libdxcompiler.so: 1.8(dev;1-df588beb)
  • Host Operating System: Compiler Explorer
@ChristianReinbold ChristianReinbold added bug Bug, regression, crash needs-triage Awaiting triage spirv Work related to SPIR-V labels Feb 16, 2024
@cassiebeckley cassiebeckley self-assigned this Feb 17, 2024
cassiebeckley added a commit to cassiebeckley/SPIRV-Tools that referenced this issue Feb 17, 2024
The folding rule `BitCastScalarOrVector` was incorrectly handling
bitcasting to unsigned 16-bit integers. It was simply copying the entire
32-bit word containing the 16-bit integer. This conflicts with the
requirement in section 2.2.1 of the SPIR-V spec which states that
unsigned numeric types with a bit width less than 32-bits must have the
high-order bits set to 0.

Fixes microsoft/DirectXShaderCompiler#6319.
cassiebeckley added a commit to cassiebeckley/SPIRV-Tools that referenced this issue Feb 17, 2024
The folding rule `BitCastScalarOrVector` was incorrectly handling
bitcasting to unsigned 16-bit integers. It was simply copying the entire
32-bit word containing the 16-bit integer. This conflicts with the
requirement in section 2.2.1 of the SPIR-V spec which states that
unsigned numeric types with a bit width less than 32-bits must have the
high-order bits set to 0.

Fixes microsoft/DirectXShaderCompiler#6319.
@cassiebeckley
Copy link
Collaborator

I believe this is actually an issue with how SPIRV-Tools folds the OpBitcast instruction for unsigned 16-bit integers. I've sent in a PR to fix it upstream.

@sudonatalie sudonatalie removed the needs-triage Awaiting triage label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug, regression, crash spirv Work related to SPIR-V
Projects
Status: Triaged
Development

Successfully merging a pull request may close this issue.

3 participants