On Fri Mar 22 22:09:42 2024 +0000, Francisco Casas wrote:
> > Another case that does not fit into "args" array is examples like
> "compile ps_2_0, main(var)", or asm {} blocks, or asm{} blocks with
> leading decl{} part. Those will have to be handled separately.
> The approach I am writing for the `compile ps_2_0 main(var)` compile
> expressions is creating a HLSL_IR_COMPILE_SHADER node type. I think this
> is necessary because these can also appear outside state blocks (which
> means they are part of regular HLSL syntax):
> ```
> PixelShader ps1 = compile ps_2_0 main();
> technique
> {
> pass
> {
> SetPixelShader(ps1);
> }
> }
> ```
> so it would be a matter of checking if rhs's arg[0] is of this type of node.
> I haven't hear of asm{} blocks before, but I assume something similar
> would happen.
...which means we would have to somewhat propagate the loads to pixel|vertex shader variables into these HLSL_IR_COMPILE_SHADER. Maybe something worth adding to the copy-propagation pass if we end up using it for rhs.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65874
On Fri Mar 22 22:01:20 2024 +0000, Francisco Casas wrote:
> We are currently lowering all dereferences into a single offset node and
> a regset (which is used to discern when variables belong to multiple
> regsets). Copy propagation also relies on this.
> Dereferences to pixel shaders and vertex shaders are created on the
> instructions originated from prepend_uniform_copy(), when the original
> uniform is copied into the temp.
> It can happen merely by declaring PixelShader or VertexShader variables
> ```
> PixelShader ps1;
> float4 main() : sv_target { return 0; }
> ```
Shouldn't DCE be killing off those dereferences?
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65872
> Another case that does not fit into "args" array is examples like "compile ps_2_0, main(var)", or asm {} blocks, or asm{} blocks with leading decl{} part. Those will have to be handled separately.
The approach I am writing for the `compile ps_2_0 main(var)` compile expressions is creating a HLSL_IR_COMPILE_SHADER node type. I think this is necessary because these can also appear outside state blocks (which means they are part of regular HLSL syntax):
```
PixelShader ps1 = compile ps_2_0 main();
technique
{
pass
{
SetPixelShader(ps1);
}
}
```
so it would be a matter of checking if rhs's arg[0] is of this type of node.
I haven't hear of asm{} blocks before, but I assume something similar would happen.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65871
On Fri Mar 22 22:01:20 2024 +0000, Zebediah Figura wrote:
> > This is required before introducing the upcoming tests because otherwise
> > we reach unreacheable code when new_offset_instr_from_deref() calls
> > type_get_regset() on pixel or vertex shaders.
> Why are we creating offset instrs for objects?
We are currently lowering all dereferences into a single offset node and a regset (which is used to discern when variables belong to multiple regsets). Copy propagation also relies on this.
Dereferences to pixel shaders and vertex shaders are created on the instructions originated from prepend_uniform_copy(), when the original uniform is copied into the temp.
It can happen merely by declaring PixelShader or VertexShader variables
```
PixelShader ps1;
float4 main() : sv_target { return 0; }
```
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65870
This fixes a performance regression introduced by 8b3944e1341baaf693927c8b758851d2dbba725a ("ntdll: Only allocate debug info in critical sections with RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO.").
Critical section was using a fallback semaphore path if no debug info is present. That was apparently to support MakeCriticalSectionGlobal() which was deprecated and removed from kernel32 exports around Win2000.
--
v2: kernel32: Make MakeCriticalSectionGlobal() a noop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5379