March 2024 - Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR5392: win32u: Avoid writing past allocated memory in peek_message().
by Paul Gofman (＠gofman) March 22, 2024

March 22, 2024

-- v2: win32u: Avoid leaking previous buffer in get_buffer_space(). https://gitlab.winehq.org/wine/wine/-/merge_requests/5392

2 2

[PATCH v7 0/3] MR4915: d3d9: Implement Direct3DCreate9On12().
by Mohamad Al-Jaf (＠maljaf) March 22, 2024

March 22, 2024

Needed by Orbiter Space Flight Simulator and Train Simulator Classic. -- v7: d3d9/tests: Add Direct3DCreate9On12() tests. d3d9: Implement Direct3DCreate9On12(). include: Add d3d9on12.idl file. https://gitlab.winehq.org/wine/wine/-/merge_requests/4915

3 6

[PATCH v6 0/3] MR4915: d3d9: Implement Direct3DCreate9On12().
by Mohamad Al-Jaf (＠maljaf) March 22, 2024

March 22, 2024

Needed by Orbiter Space Flight Simulator and Train Simulator Classic. -- v6: d3d9/tests: Add Direct3DCreate9On12() tests. d3d9: Implement Direct3DCreate9On12(). https://gitlab.winehq.org/wine/wine/-/merge_requests/4915

4 17

[PATCH 0/1] MR5392: win32u: Avoid writing past allocated memory in peek_message().
by Paul Gofman (＠gofman) March 22, 2024

March 22, 2024

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5392

2 2

Re: [PATCH v2 0/7] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Zebediah Figura (＠zfigura) March 22, 2024

March 22, 2024

On Fri Mar 22 22:39:11 2024 +0000, Francisco Casas wrote: > DCE happens after offsets are lowered. I would solve that problem by running it again, then, earlier. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65875

1 0

Re: [PATCH v2 0/7] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) March 22, 2024

March 22, 2024

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

1 0

Re: [PATCH v2 0/7] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) March 22, 2024

March 22, 2024

On Fri Mar 22 22:18:25 2024 +0000, Zebediah Figura wrote: > Shouldn't DCE be killing off those dereferences? DCE happens after offsets are lowered. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65873

1 0

Re: [PATCH v2 0/7] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Zebediah Figura (＠zfigura) March 22, 2024

March 22, 2024

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

1 0

Re: [PATCH v2 0/7] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) March 22, 2024

March 22, 2024

> 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

1 0

Re: [PATCH v2 0/7] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) March 22, 2024

March 22, 2024

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

1 0