What causes "Operand kind not recognized" in stride3d/stride?

Upgrade Stride.Shaders.Spirv to a version that recognizes the newer SPIR-V spec operand kinds

stride3d/stride · error · NotImplementedException

Operand kind not recognized

Error message

Operand kind not recognized

What it means

LogicalOperand.GetWordSize maps each SPIR-V operand kind to its word count. The switch covers all known kinds but its default arm throws NotImplementedException for an OperandKind value it does not recognize, which can only happen with an unknown/extended kind produced by a newer SPIR-V specification or a corrupt instruction stream.

Solutions

Upgrade Stride.Shaders.Spirv to a version that recognizes the newer SPIR-V spec operand kinds
Regenerate/re-export the SPIR-V module with an older toolchain whose operand kinds match the supported grammar
Validate the bytecode with spirv-val to rule out corruption, then re-serialize it canonically

Example fix

// before
var bytecode = CompileWithNewestGlslang(source); // emits operand kinds this parser lacks
// after
var bytecode = CompileWithGlslangVersion(source, "11.1.2"); // matches supported SPIR-V 1.5 grammar

Defensive patterns

Strategy: try-catch

Validate before calling

// Prefer validating the module with spirv-val before decoding with this library
// and pin the SPIR-V version your pipeline emits:
if (header.Version > SupportedMaxVersion)
    throw new NotSupportedException($"SPIR-V {header.Version} exceeds parser-supported grammar.");

Try / catch

try
{
    var size = LogicalOperand.GetWordSize(kind);
}
catch (NotImplementedException)
{
    log.Error("Unknown SPIR-V operand kind; module was produced by a newer spec or is corrupt.");
}

Prevention

Keep the SPIR-V emitting toolchain version compatible with the parser library version
Run spirv-val on modules before feeding them to custom decoders
Re-serialize modules with spirv-opt to normalize operand layouts

When it happens

Trigger: Decoding a SPIR-V module whose instruction operand kinds include a value outside the enumerated LogicalOperand kinds — e.g. a module generated by a newer SPIR-V spec version than this library supports, or a corrupted bytecode where the instruction layout is misread and a wrong kind is derived.

Common situations: Parsing SPIR-V emitted by a newer glslang/spirv-tools than the parser supports; a misaligned/corrupted bytecode stream causing operand misinterpretation; extension-specific operands the library has not mapped.

Related errors

AI-assisted analysis of stride3d/stride@96fad776d2 (2026-09-14). Data as JSON: /api/errors/6a9203ab583f6ef4. Report an issue: GitHub.

Appendix: source

Thrown at sources/shaders/Stride.Shaders.Spirv/Information/LogicalOperand.Size.cs:72

            or OperandKind.KernelEnqueueFlags
            or OperandKind.Capability
            or OperandKind.RayQueryIntersection
            or OperandKind.RayQueryCommittedIntersectionType
            or OperandKind.RayQueryCandidateIntersectionType
            or OperandKind.IdResultType
            or OperandKind.IdResult
            or OperandKind.IdMemorySemantics
            or OperandKind.IdScope
            or OperandKind.IdRef
            or OperandKind.LiteralInteger => 1,
            OperandKind.LiteralString => -1,
            OperandKind.LiteralContextDependentNumber => -1,
            OperandKind.LiteralExtInstInteger => 1,
            OperandKind.LiteralSpecConstantOpInteger => 1,
            OperandKind.PairLiteralIntegerIdRef => 2,
            OperandKind.PairIdRefLiteralInteger => 2,
            OperandKind.PairIdRefIdRef => 2,
            _ => throw new NotImplementedException("Operand kind not recognized")
        };
    }
}

View on GitHub (pinned to 96fad776d2)