microsoft
Attributes read via `GetAttributeAtVertex` aren't counted as read in the signature
Description
float4 VCMain(
nointerpolation float4 Color:COLOR0)
: SV_TARGET0
{
#ifdef USE_GET_ATTRIBUTE_AT_VERTEX
return GetAttributeAtVertex(Color,0);
#endif
return Color;
}
Steps to Reproduce
With above shader the generated assembly shows the input signature. When compiled without extra defines, it reports:
; Input signature:
;
; Name Index Mask Register SysValue Format Used
; -------------------- ----- ------ -------- -------- ------- ------
; COLOR 0 xyzw 0 NONE float xyzw
When compiled with -DUSE_GET_ATTRIBUTE_AT_VERTEX it shows:
; Input signature:
;
; Name Index Mask Register SysValue Format Used
; -------------------- ----- ------ -------- -------- ------- ------
; COLOR 0 xyzw 0 NONE float
My expectation here is that COLOR would show as used in both cases.
Environment
- dxcompiler.dll: 1.7 - 1.7.2212.40 (e043f4a12); dxil.dll: 1.7(101.7.2212.36)
- Windows 11
There is some nuance here. The actual values of color are not being used rather the variable is being used to access the 0th barycentric value. I don't know necessarily if that would cause a problem here. @damyanp, did you encounter a specific bug from this? @tex3d, do you think this is a problem or working as intended?
If backend only depends on the value of used to decide which ps input is required, that will be a problem.
If backend collects the information when lower attributeAtVertex and loadInput, things should be fine.
This was reported by a developer who wants to use reflection to determine which vertex attributes are actually used by a shader after dead code has been eliminated.
I think this is a legitimate bug - we should be including this operation when computing the usage mask.
These masks are used when validating inter-stage signature linkage, so if the input appears unused, it would appear that the corresponding output from the upstream shader does not need to be written. That doesn't sound like the right behavior.
Hello, This is still a legitimate bug and we would love to see it solved. Thank you,
