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

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

March 22, 2024

Zebediah Figura (@zfigura) commented about libs/vkd3d-shader/hlsl.h: > + * name[lhs_array_size] = args[0] > + * - or - > + * name[lhs_array_size] = {args[0], args[1], ...}; > + * FX function call: > + * name(args[0], args[1], ...); > + */ > +struct hlsl_state_block_entry > +{ > + bool is_function_call; > + > + /* For assignments, the name in the lhs. For function calls, the name of the function. */ > + char *name; > + > + /* Whether the lhs in an assignment is an array and, in that case, its size. */ > + bool lhs_is_array; > + unsigned int lhs_array_size; I suspect this is rather an index. Effect documentation is nonexistent, but [1] shows some hints, this is probably how you set per-RT blend states. It's probably worth testing with an actual effect target to see if BlendEnable is different from BlendEnable[0]. [1] https://learn.microsoft.com/en-us/windows/win32/direct3d11/d3d11-effect-var… -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65841

1 0

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

March 22, 2024

Nikolay Sivov (@nsivov) commented about libs/vkd3d-shader/hlsl.h: > + /* Whether the lhs in an assignment is an array and, in that case, its size. */ > + bool lhs_is_array; > + unsigned int lhs_array_size; > + > + /* For assignments, instructions present in the rhs. For function calls, instructions present > + * in the function arguments. */ > + struct hlsl_block *instrs; > + > + /* For assignments, arguments of the rhs initializer. For function calls, the function > + * arguments. */ > + struct hlsl_ir_node **args; > + unsigned int args_count; > + > + /* For assignments, whether the rhs is wrapped in braces or not. */ > + bool rhs_braces; > +}; My concern, just by looking at it, is about how hard would it be to extract relevant cases from instructions. Is it easy to tell already that we got a constant load, array variable load with constant index, array variable load with variable index, or more complicated expression? Those are important to distinguish, because they are encoded differently. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65840

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

> +% For now, these tests are just to check proper parsing of effects syntax. > +% Most of these tests are useless as effects. This file is very large; I'd propose splitting it into state-block-syntax (which already exists) and something more like effect-state and effect-shaders? -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65839

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

> 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? -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739#note_65838

1 0

[PATCH 0/1] MR5390: user32/tests: Further updates for win11 TrackPopupMenu failures.
by Esme Povirk (＠madewokherd) March 22, 2024

March 22, 2024

https://test.winehq.org/data/b053e924e8e13b3637f2a5a8ffe88d84c2d17075/w1121… This should hopefully be the last of these updates, since the test output shows it "resyncing" with the expected data. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5390

2 1

[PATCH 0/3] MR5356: server: Replace sprintf with snprintf/asprintf to avoid deprecation warnings on macOS.
by Brendan Shanks (＠bshanks) March 22, 2024

March 22, 2024

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

3 4

[PATCH v3 0/2] MR5269: Add NtQueryInformationProcess(ProcessQuotaLimits) stub
by Gijs Vermeulen (＠gverm) March 22, 2024

March 22, 2024

Based on a patch by Qian Hong. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44812 -- v3: ntdll: Add NtQueryInformationProcess(ProcessQuotaLimits) tests. ntdll: Add NtQueryInformationProcess(ProcessQuotaLimits) stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/5269

5 5

[PATCH 0/1] MR5389: kernel32, ntdll: Don't use debug info presence to detect critical section global status.
by Paul Gofman (＠gofman) March 22, 2024

March 22, 2024

See https://gitlab.winehq.org/wine/wine/-/merge_requests/5379 , this is an alternative way which doesn't remove MakeCriticalSectionGlobal() functionality. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5389

2 1

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

March 22, 2024

I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally. As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata. A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with. Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739

3 8

[PATCH 0/4] MR708: Draft: vkd3d-shader: Porposal for parsing state blocks.
by Francisco Casas (＠fcasas) March 22, 2024

March 22, 2024

Currently we are assuming that unknown identifiers within state blocks are scalar integers. This proposal keeps doing this. The lower_static_constant_folding() meta-pass is introduced to fold as much as possible these state state block expressions. And I plan to reuse it for constant buffer default values. A lower_state_block_identifier_loads() pass is included in the last commit. The idea is to start filling a table with numeric values for the unknown identifiers as we start discovering them. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708

4 32