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

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

March 23, 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 23, 2024

March 23, 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

[PATCH v2 0/1] MR5379: kernel32: Make MakeCriticalSectionGlobal() a noop.
by Paul Gofman (＠gofman) March 22, 2024

March 22, 2024

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

4 11

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

March 22, 2024

On Fri Mar 22 21:20:30 2024 +0000, Francisco Casas wrote: > well, first we have to find out if native does some compilation passes > such as copy-propagation and constant folding to lower complicated > expressions into constants, and apply those passes. For instance, are > rhs expressions such as `ANISOTROPIC + 1` marked as a of the _constant > load_ type in the effects metadata? > After applying the passes we have to check the type of the last > instruction of the block (or args[0], in case ths is not a complex > initializer with braces) which represents the whole expression, and see > if it is HLSL_IR_CONSTANT, HLSL_IR_INDEX (in which case we have to check > if the index part is constant) or HLSL_IR_EXPR. > We should also probably introduce a pass exclusive to fx.c to lower > known HLSL_IR_UNDECLARED_LOAD into constants, so constant folding (if > required) can work. > I don't know yet how complex initializers with braces work in this case, > if at all, but they parse. They are evaluated, yes. Destination index is not evaluated, it has to be an integer literal. So full format would be like this: property_name[<literal index>] = ( literal_constant | variable[literal_constant] | variable[index_variable] | <expression-for-anything-more-complicated> ) Expression case does not map directly to our internal opcodes, it does not follow the same conventions as d3dbc/tpf binaries do. But we can leave that out for now. 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. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65867

1 0