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

OperandExceeded when using specialization constants in work group size #121

Closed
alixinne opened this issue Feb 20, 2020 · 2 comments · Fixed by #151
Closed

OperandExceeded when using specialization constants in work group size #121

alixinne opened this issue Feb 20, 2020 · 2 comments · Fixed by #151
Assignees

Comments

@alixinne
Copy link

Context

Given the following GLSL compute shader which defines its work group size using specialization constant 0:

#version 460

layout(local_size_x_id = 0) in;

void main() {
    int kernelId = int(gl_WorkGroupSize.x);
}

Compiling it using shaderc result in the following (disassembled using spirv-dis) SPIR-V file:

; SPIR-V
; Version: 1.0
; Generator: Google Shaderc over Glslang; 7
; Bound: 17
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %main "main"
               OpExecutionMode %main LocalSize 1 1 1
               OpSource GLSL 460
               OpSourceExtension "GL_GOOGLE_cpp_style_line_directive"
               OpSourceExtension "GL_GOOGLE_include_directive"
               OpName %main "main"
               OpName %kernelId "kernelId"
               OpDecorate %10 SpecId 0
               OpDecorate %gl_WorkGroupSize BuiltIn WorkgroupSize
       %void = OpTypeVoid
          %3 = OpTypeFunction %void
        %int = OpTypeInt 32 1
%_ptr_Function_int = OpTypePointer Function %int
       %uint = OpTypeInt 32 0
         %10 = OpSpecConstant %uint 1
     %uint_1 = OpConstant %uint 1
     %v3uint = OpTypeVector %uint 3
%gl_WorkGroupSize = OpSpecConstantComposite %v3uint %10 %uint_1 %uint_1
     %uint_0 = OpConstant %uint 0
         %15 = OpSpecConstantOp %uint CompositeExtract %gl_WorkGroupSize 0
         %16 = OpSpecConstantOp %int IAdd %15 %uint_0
       %main = OpFunction %void None %3
          %5 = OpLabel
   %kernelId = OpVariable %_ptr_Function_int Function
               OpStore %kernelId %16
               OpReturn
               OpFunctionEnd

Expected behavior

Parsing the module using rspirv succeeds.

Observed behavior

Trying to parse the resulting binary module with rspirv results in the following error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: OperandExceeded(436, 23)', src/libcore/result.rs:1188:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1025
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:193
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:471
  11: rust_begin_unwind
             at src/libstd/panicking.rs:375
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:84
  13: core::result::unwrap_failed
             at src/libcore/result.rs:1188
  14: core::result::Result<T,E>::unwrap
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/result.rs:956
  15: rspirv_bug::main
             at src/main.rs:6
  16: std::rt::lang_start::{{closure}}
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/rt.rs:67
  17: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  18: std::panicking::try::do_call
             at src/libstd/panicking.rs:292
  19: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  20: std::panicking::try
             at src/libstd/panicking.rs:270
  21: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  22: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  23: std::rt::lang_start
             at /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libstd/rt.rs:67
  24: main
  25: __libc_start_main
  26: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Affected versions

  • Current state of the master branch (#3905855)
  • Latest version published on crates.io (0.5.4)

How to reproduce the bug

See example code at https://github.com/vtavernier/rspirv-bug. Clone and use cargo run to check.

@Jasper-Bekkers
Copy link
Collaborator

@vtavernier Could you take a look at the PR and see if it fixes your issue? I think we were parsing OpSpecConstantOp incorrectly before.

@alixinne
Copy link
Author

The PR indeed fixes the issue, thanks!

Jasper-Bekkers added a commit that referenced this issue Aug 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants