Can you please post the DXBC shader binary so that I can actually try and reproduce this?
Actually yeah, we don't support fallthrough with code. The D3D11 spec calls this out as invalid, and somewhere else it says
D3D10 allowed this, but HLSL never exposed it.
so the question is, how on earth are you generating that shader code?
This is somewhat hard to work around on our end since SPIR-V also does not support this directly.
Dx10/dx11 both support fall though, but dx11 has limitation:
The exception is for D3D11, case/default statements that
fall through to the next case/default without a break cannot
have any code in them. D3D10 allowed this, but HLSL never
exposed it. It is still permitted for multiple
case statements (incl default) to appear sequentially
(sharing the same code block).
Hope you can receive the binary.
发件人: Philip Rebohle @.***
发送时间: 2022年3月22日 17:16
收件人: doitsujin/dxvk @.>
抄送: Neo Yu(WH-RD) @.>; Author @.***>
主题: Re: [doitsujin/dxvk] spirv seems wrong for switch-case (Issue #2556)
Actually yeah, we don't support fallthrough with code. The [D3D11 spec](https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_3_FunctionalSpec.htm#22.7.12 case (in switch)) calls this out as invalid, and for switch itself it says
D3D10 allowed this, but HLSL never exposed it.
so the question is, how on earth are you generating that shader code?
—
Reply to this email directly, view it on GitHubhttps://github.com/doitsujin/dxvk/issues/2556#issuecomment-1074916905, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXAWBIE25CUPGWG3T6M3IZTVBGFULANCNFSM5RJZGZQA.
You are receiving this because you authored the thread.Message ID: @.***>
保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
We do support the D3D11 case, just not the fallthrough with code. This is why both cases point to the same label in your shader, since we're assuming that the block between multiple cases is empty.
so will you support this for dx10, or we can provide a fix?
I can try to fix this, but as mentioned I'll need a way to test this with a real binary.
thanks a lot, how can i upload the binary, i tried post binary via mail, seems fail
Thanks, got the mail.
Should be fixed as of b015cf0bb23c669496379a265dc40170dfb793aa.
Turns out I was wrong about SPIR-V not supporting fallthrough, it actually is legal, although I'm not sure if this is well-tested in current Vulkan drivers.
Hi @doitsujin ,
I met a dx10 dxbc shader, and the dxbc compiler generated spirv seems wrong. there is no break in case0 or case1, so no new label ID is generted, and case0/case1/default all use the same lable ID 60. can you help check, thanks a lot.
DXBC:
vs_4_0
0. dcl_constantBuffer c0[20], dynamicIndexed
part of spirv:
56: 8(fvec4) Load 46(r7)
57: 7(float) CompositeExtract 56 0
58: 5(int) Bitcast 57
SelectionMerge 59 None
Switch 58 60
case 0: 60
case 1: 60
60: Label
best wishes
-neo