April 2024 - wine-gitlab

[PATCH 0/3] MR772: vkd3d: Add two more resource description/state validations.
by Conor McCarthy (＠cmccarthy) 09 Apr '24

09 Apr '24

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/772

4 5

[PATCH v4 0/5] MR767: vkd3d-shader/dxil: Tessellation part 1.
by Conor McCarthy (＠cmccarthy) 09 Apr '24

09 Apr '24

Doesn't support tessellation yet, but adds some requirements. -- v4: vkd3d-shader/ir: Validate tessellation declarations. vkd3d-shader/dxil: Implement DX intrinsic PrimitiveID. vkd3d-shader/dxil: Load hull shader properties. vkd3d-shader/dxil: Load domain shader properties. tests/hlsl: Add a tessellation test. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/767

5 17

[PATCH v3 0/5] MR765: tests: Do not crash on llvmpipe.
by Giovanni Mascellani (＠giomasce) 09 Apr '24

09 Apr '24

-- v3: ci: Build Mesa for release. tests: Pop the test context when leaving its scope. tests: Add llvmpipe among the Mesa drivers. tests: Skip tests that crash on llvmpipe. tests: Do not crash on some test failures. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/765

3 7

Re: [PATCH v3 0/1] MR761: tests/shader_runner: Report compilation errors on the block's starting line.
by Henri Verbeet (＠hverbeet) 09 Apr '24

09 Apr '24

> > This seems a little fragile. > > I don't think it is that fragile, currently we handle directives in 3 points in run_shader_tests(): > > 1. The first switch, where we detect that we stopped reading the block because a new block starts or the file ended. > 2. The reading of the tags at the beginning of new blocks. > 3. The reading of individual lines using a second switch. > > We don't need to call update_line_number_context() in 1, and we always have to call it in 2 so we don't have to worry about forgetting to do so we add new functionalities. > > It is only in 3 that we have to remember to call update_line_number_context() for the switch cases when we want to update the line number context for each line instead of presenting it at the beginning of the block, but even if we forget, the error will be reported at the beginning of the block because of 2. Sure, the impact of messing up isn't going to very bad. Fundamentally though, this commit puts the burden of calling update_line_number_context() on the "normal" cases instead of on the exceptional cases. > > Could we just track the starting line for things touching "shader_source" and then setup/restore the test context in e.g. compile_shader()? > > Here is a patch for that proposal (how I see it), but I find it more complex. > > [0001-tests-shader-runner-Report-compilation-errors-on-the.patch](https://gi… I think that's closer to what I had in mind. How do you feel about [this patch](/uploads/e4b238bc14f76573c5eea824d660402f/patch.diff)? -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/761#note_67388

1 0

[PATCH v7 0/1] MR5188: Draft: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
by Tim Clem (＠tclem) 09 Apr '24

09 Apr '24

This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam). The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that: 1. That *should* be an anomalous case, such as the app hanging on exit. 2. Effectively the same behavior would happen on Windows. I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns. -- v7: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/5188

2 1

[PATCH v6 0/10] MR739: vkd3d-shader/hlsl: Parse state blocks, part 1.
by Francisco Casas (＠fcasas) 09 Apr '24

09 Apr '24

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. -- v6: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs. vkd3d-shader/hlsl: Store state block on pass variables. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739

2 11

[PATCH v2 0/6] MR773: Draft: vkd3d-shader/ir: Try harder to move `break's to the end of loops.
by Giovanni Mascellani (＠giomasce) 09 Apr '24

09 Apr '24

This goes atop !764. The last three commits belong to this MR. Since we want to get rid of loops and `break's as much as possible, we try to move `break's out of selection constructs as much as possible so it's easier to match them with loops. This MR introduces a few other tricks to help that. -- v2: vkd3d-shader/ir: Move breaks out of selections again after having optimized loops. vkd3d-shader/ir: Append code to the non-breaking branch if there is breaking one. vkd3d-shader/ir: Prepare for changing the destination list in vsir_cfg_optimize_recurse(). vkd3d-shader/ir: Remove loops that terminate with a `break'. vkd3d-shader/ir: Count how many jumps target each loop. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/773

2 6

[PATCH 0/6] MR773: Draft: vkd3d-shader/ir: Try harder to move `break's to the end of loops.
by Giovanni Mascellani (＠giomasce) 09 Apr '24

09 Apr '24

This goes atop !764. The last three commits belong to this MR. Since we want to get rid of loops and `break's as much as possible, we try to move `break's out of selection constructs as much as possible so it's easier to match them with loops. This MR introduces a few other tricks to help that. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/773

2 7

[PATCH 0/3] MR5477: msi/tests: Try restarting tests elevated.
by Hans Leidekker (＠hans) 09 Apr '24

09 Apr '24

Wine starts processes non-elevated since e92ba2de43d7afbe0704b11b29f7c30f44dfaeca which means that many tests are skipped now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5477

3 4

[PATCH 0/3] MR5478: winegcc/winebuild: Add -marm64x option support.
by Jacek Caban (＠jacek) 09 Apr '24

09 Apr '24

On MSVC, building hybrid ARM64X images requires executing linker directly, with `-machine:arm64x` option, there is not way to use the compiler as a linker driver in such case. Clang git version has `-marm64x` option now, which allows using it as a linker driver for ARM64X builds. This MR adds a similar option to winegcc and winebuild. For winegcc, we need to build spec file objects for both targets (native and EC). winebuild uses a new llvm-dlltool option `-N`, which works like MSVC lib.exe's `/defArm64Native` and allows passing .def files for both targets to generate a hybrid import library. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5478

2 3

2025

2024

2023

2022

wine-gitlab April 2024