Description
Hull shader is supposed to have a special pass-through case triggered when you copy input for corresponding SV_OutputControlPointID directly to a compatible output. The pass-through case should result in no manual copying of control point inputs to control point outputs, instead using a null entry function pointer, or something like that.
There are problems blocking this scenario:
the compiler does not recognize the scenario in the first place
I cannot even craft any scenario I can think of directly in DXIL that successfully validates
Conflicting assumptions about what this should even look like in different areas of code
In metadata loading, code assumes that a null metadata node for the shader function in the entry list denotes the pass-through case.
If you attempt this, the validator will crash because it relies on a map of function pointers to entry properties, which will cause it to fail to look up the entry properties for the function. Even DxilModule relies on a map of function pointer to entry properties, so there are deep problems with this representation.
The validator seems to assume that the pass through case will be denoted by a declaration for the entry function, instead of a definition, at least in the code that is supposed to be validating the pass through case. But if you try this, another part of the validator will say it's invalid because it sees this as an invalid DXIL intrinsic, assuming DXIL intrinsics are the only external function declarations allowed, besides llvm intrinsics.
Actual Behavior
No error occurs, but the control point function produced loads and stores each value, instead of matching the expected degenerate pass-through case.
It seems there's multiple issues here, at least one of them is a bug in the validator that we'll want to address, so we'll likely need to split this issue up.
Description Hull shader is supposed to have a special pass-through case triggered when you copy input for corresponding
SV_OutputControlPointID
directly to a compatible output. The pass-through case should result in no manual copying of control point inputs to control point outputs, instead using a null entry function pointer, or something like that.There are problems blocking this scenario:
In metadata loading, code assumes that a null metadata node for the shader function in the entry list denotes the pass-through case. If you attempt this, the validator will crash because it relies on a map of function pointers to entry properties, which will cause it to fail to look up the entry properties for the function. Even
DxilModule
relies on a map of function pointer to entry properties, so there are deep problems with this representation.The validator seems to assume that the pass through case will be denoted by a declaration for the entry function, instead of a definition, at least in the code that is supposed to be validating the pass through case. But if you try this, another part of the validator will say it's invalid because it sees this as an invalid DXIL intrinsic, assuming DXIL intrinsics are the only external function declarations allowed, besides llvm intrinsics.
Steps to Reproduce
Actual Behavior No error occurs, but the control point function produced loads and stores each value, instead of matching the expected degenerate pass-through case.
Environment