Please provide an example HLSL shader that can generate the problem code with FXC.
SHADER4E7219D3.zip
this is the dxbc binary code.
Please provide an example HLSL shader that can generate the problem code with FXC.
hi, a dxbc binary file is provided now.
Can you please provide the HLSL that generates this?
If you are generating your own DXBC, then yes, it probably doesn't work if it relies on patterns FXC will not emit.
Can you please provide the HLSL that generates this?
If you are generating your own DXBC, then yes, it probably doesn't work if it relies on patterns FXC will not emit.
What I encountered was this DXBC binary file. I don't have HLSL file. this binary file is not generate by me.
Does anything use that shader?
I don't know how far we're willing to go to accommodate broken DXBC but it would at the very least be nice to know what it would fix.
We could work around this, but I'd also like to know what the use case here is other than intentionally feeding us broken code.
Also, please note that we have no plans to support subroutines, which is where label instructions are usually used.
Also, can you please post the unmodified shader binary as you would pass it to D3D11? I don't know what format the shader file you attached is in but it's most certainly not a DXBC binary, so I can't even disassemble it to see the code.
Also, can you please post the unmodified shader binary as you would pass it to D3D11? I don't know what format the shader file you attached is in but it's most certainly not a DXBC binary, so I can't even disassemble it to see the code.
We tested our code using some test shaders, and this shader caused a crash in DXBC. this shader is downloaded from the SandBox website. Attached is the asm code.
SHADER4E7219D3.zip
Is there really no way for you to extract the shader binary that you're passing to your own D3D11 application? There's no way to generate this code with FXC that I know of, and there is no way to compile DXBC assembly to a binary either. I simply cannot work with this.
If you want us to fix handling of dead code then we need a valid shader binary to be able to test that. I could try to generate a similar binary by hand but that's a bunch of work.
That being said, it's rather suspicious that the binary contains dead code to begin with. This should probably be looked at from the binary generator side of things.
https://github.com/doitsujin/dxvk/tree/dxbc-dead-code may or may not fix this. As mentioned, I'm unable to test this, and this will require significant amounts of testing especially with tessellation shaders.
https://github.com/doitsujin/dxvk/tree/dxbc-dead-code may or may not fix this. As mentioned, I'm unable to test this, and this will require significant amounts of testing especially with tessellation shaders.
Thank you, This commit of yours can solve my problem. I tested my shader locally, and it passed.
https://github.com/doitsujin/dxvk/tree/dxbc-dead-code may or may not fix this. As mentioned, I'm unable to test this, and this will require significant amounts of testing especially with tessellation shaders.
tested one crash because lack of this line:
&& ins.opClass != DxbcInstClass::Interface
@ecoling what do you mean exactly? DxbcInstClass::Interface does not exist.
Please try to be more precise when reporting things like this because without any sort of test case it's very hard to fix this stuff to begin with.
I will revert the commit if I do not get an answer (or run into a test case that crashes) soon.
Nothing extracted yet.
We meet some strange dxbc like this.
MS DX10/11 PS Instructions:
...
label l[0]
ret
mov r0, r4
ret
when compile this code to SPIRV, the first ret instruction emit a OpFunctionEnd Instructions.
but this function isn't actually end, the OpFunctionEnd should be generated by the second ret instruction.