The code doesn't make sense in the first place, even if it's
accepted by the compiler, so it makes sense that the behaviour
is undefined. And indeed the behaviour is different on AMD (4 is
returned), NVIDIA (QNaN is returned) and WARP (device is removed).
Currently program errors might result on instructions that use
ctx->error_instr as src. In case we hit YYABORT while parsing another
part of the HLSL source, we have to make sure that the block that
contains the instruction is properly cleaned up, or we might hit the
vkd3d:590273:err:hlsl_free_instr Failed assertion: list_empty(&node->uses)
assertion when hlsl_ctx_cleanup() is called after the YYABORT.
Consider the following shader:
float4 main() : sv_target
{
// Statement A
int p = foo; // initializer argument is ERROR.
// Statement B
undeclared_fun(); // triggers YYABORT.
}
Statement A will src the ctx->error_instr because of the undeclared
identifier and Statement B will trigger an YYABORT because of the
undeclared function.
The stride didn't match the structure size used in the shader.
This didn't seem to be a problem on AMD and WARP, but it was
on NVIDIA on Windows. Specifically, it seems that the buffer
is read using the shader structure size (so most tests pass),
but bounds are checked using the buffer stride, so a test
returned zero simply because an out-of-bounds read was detected.
Unless the D3D11_FEATURE_DATA_D3D11_OPTIONS2.MapOnDefaultTextures
feature is supported, textures with default usage cannot be read by the
CPU; and there isn't a need to either, since we're going through a
staging texture anyway.
This worked on AMD and WARP, but failed on NVIDIA on Windows.
