[Bug 59687] New: 'const' variable modifier causes null return-value in vertex shader
http://bugs.winehq.org/show_bug.cgi?id=59687 Bug ID: 59687 Summary: 'const' variable modifier causes null return-value in vertex shader Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@list.winehq.org Reporter: bczhc0@126.com Distribution: --- Created attachment 80789 --> http://bugs.winehq.org/attachment.cgi?id=80789 trace-ok.log Take this HLSL code which basically is a hello-triangle. ```hlsl struct VsOut { float4 pos : SV_Position; }; static const float2 VERTICES[3] = { float2(0.0, 0.5), float2(-0.5, -0.5), float2(0.5, -0.5) }; static const float4 RED = float4(1.0, 0.0, 0.0, 1.0); VsOut vs_main(uint vid : SV_VertexID) { float2 position = VERTICES[min(vid, 2u)]; VsOut output = { float4(position, 0.0, 1.0) }; return output; } float4 fs_main() : SV_Target { return RED; } ``` I have this wgpu program: https://gist.github.com/bczhc/e8d11db2280ffd20fee43fb1fed7410e to run and render this shader. (Sorry I'm not familiar with hlsl and windows programming so I just now only able to write the wgpu program to demonstrate it and suppose it may not be related to wgpu anyway) To compile and run it, do: ```bash # ensure to put it in a cargo project first cargo build --target x86_64-pc-windows-gnu # run WINEPREFIX=`pwd`/prefix WGPU_BACKEND=dx12 wine target/x86_64-pc-windows-gnu/debug/demo.exe the-hlsl-above.hlsl vs_main ``` It will display a red triangle. However, modify this line `VsOut output = { float4(position, 0.0, 1.0) };` to `const VsOut output = { float4(position, 0.0, 1.0) };`, then compile the Rust program then run it using wine again, the red triangle will not show. Or, if that line is left as is but you add another const variable, like this: ```hlsl VsOut vs_main(uint vid : SV_VertexID) { float2 position = VERTICES[min(vid, 2u)]; VsOut output = { float4(position, 0.0, 1.0) }; const VsOut output1 = output; return output1; } ``` The red triangle is also not able to display. This is originally reported as a wgpu issue here: https://github.com/gfx-rs/wgpu/issues/9056. At that time, only proton has this issue (wine is okay). However now with wine 11.6 I tested it again, wine has this issue either. So I suspect this is an upstream vkd3d hlsl compiler issue then? I haven't done the bisect yet because I haven't managed how to properly compile this project and substitute it for wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 --- Comment #1 from Zhai Can <bczhc0@126.com> --- Created attachment 80790 --> http://bugs.winehq.org/attachment.cgi?id=80790 trace-with-const.log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 Zhai Can <bczhc0@126.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bczhc0@126.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 Zhai Can <bczhc0@126.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|11.6 |1.19 Product|Wine |vkd3d Component|d3d |hlsl -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #2 from Zeb Figura <z.figura12@gmail.com> --- The problem is we look at a const expression with an initializer and think that it's a compile-time constant. A load isn't enough to prevent that. I think I assumed that is_static_expression() was passed the entire block of instructions used in computation, but of course that's not the case; it's only passed the block constructed for the initializer args. We should probably be tracking and storing in individual variables whether they're compile-time constants and then checking that for loads in is_static_expression(). I didn't trace through the entire code, but I think the effect of is_static_expression() returning true here is that we add the initializer to ctx->static_initializers instead of the block where it should be. That means it's ordered before the instructions it depends on. I'm surprised that doesn't cause an assertion but in practice it looks like DCE ends up deleting pretty much everything first. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 --- Comment #3 from Zeb Figura <z.figura12@gmail.com> --- Corollary question so I don't forget it: should we even be checking CONST at all here? Whether a variable is resolvable to a compile time constant doesn't really depend on whether it's marked const at all. I'm pretty sure we have tests that say that native only considers them to be compile-time consts with CONST though. Still I should double check that. [This is important for the purpose of things like array size or sample count.] -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 Francisco Casas <fcasas@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcasas@codeweavers.com --- Comment #4 from Francisco Casas <fcasas@codeweavers.com> --- Hi, thank you for the detailed Bug report, and Zeb for the additional insights. This should be fixed by https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/1997
Corollary question so I don't forget it: should we even be checking CONST at all here? Whether a variable is resolvable to a compile time constant doesn't really depend on whether it's marked const at all.
I think whether it is CONST or not matters, consider the following shader: ``` float4 main() : sv_target { const int b = 4; float arr[b]; return 0; } ``` compilation fails in native if 'const' is removed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59687 --- Comment #5 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Francisco Casas from comment #4)
Corollary question so I don't forget it: should we even be checking CONST at all here? Whether a variable is resolvable to a compile time constant doesn't really depend on whether it's marked const at all.
I think whether it is CONST or not matters, consider the following shader:
Yeah, that's what I thought, but I wrote that comment over breakfast and hadn't double-checked the tests yet. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla