July 2023 - wine-gitlab

[PATCH 0/14] MR3266: mshtml: dom tests leak fixes.
by Gabriel Ivăncescu (＠insn) 07 Jul '23

07 Jul '23

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

3 15

[PATCH 0/6] MR3238: wined3d: Move Vulkan declarations to wined3d_vk.h, part 1/3.
by Zebediah Figura (＠zfigura) 07 Jul '23

07 Jul '23

This is a part of a larger effort to reorganize wined3d a bit so that backend functions are fully quarantined into their own files. There are a few advantages to this: * We avoid including (large) headers in files that don't need them. * This has helped me find functions that are currently incorrectly tied to backends [e.g. wined3d_texture_update_desc(), wined3d_texture_set_lod()]. * This may also help find code (struct members, helpers, etc.) which should be made local to a backend. * I find that this aids the reader in logically separating wined3d code. For some time the wined3d code base has resisted modularity of compilation units, simply on the grounds that this is not necessary. I find files comprising several thousand lines to be a bit unwieldy, however, and that comprehension and navigation are eased when drawing physical lines even when such separation was already obvious. It also can be nice for compilation speed. There are a few steps to this: - move GL and Vulkan declarations to wined3d_gl.h and wined3d_vk.h respectively - introduce "resource_gl.c" and "resource_vk.c", and move most resource code to those functions. This collapses the separation between buffer, texture, sampler, and view code, though, and there may be some benefit in keeping those separate. It's worth mentioning though that the bulk of those files ends up being the texture code. It's also worth mentioning that resources are generally interrelated—e.g. views delegate to buffers or textures—and we've talked about generalizing more of the buffer/texture code to share more code. Of course, *everything* is interrelated, so the lines that we're drawing now are kind of arbitrary. I at least find that GL/Vulkan are *useful* lines to draw. - add format_gl.c, because there are about 3000 lines of code to deal with GL format detection. - add ffp_gl.c, which contains the fixed-function vertex and fragment pipelines. This is about 3500 lines. - move other functions to backend-specific adapter or context functions, where it makes sense. Swapchain code mostly gets moved to context_*.c, though I'm not sure whether that makes the most sense or not. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3238

5 11

[PATCH 0/1] MR3265: gdi32: Fix DIB_PAL_INDICES usage handling in EMR_CREATEMONOBRUSH playback.
by Piotr Caban (＠piotr) 07 Jul '23

07 Jul '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55177 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3265

3 2

[PATCH v3 0/6] MR259: vkd3d-shader/dxil: Read the DXIL module.
by Conor McCarthy (＠cmccarthy) 07 Jul '23

07 Jul '23

-- v3: vkd3d-shader/dxil: Read function bodies. vkd3d-shader/dxil: Read numeric constants. vkd3d-shader/dxil: Read global function declarations. vkd3d-shader/dxil: Validate the module format version. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/259

2 6

[PATCH v2 0/6] MR259: vkd3d-shader/dxil: Read the DXIL module.
by Conor McCarthy (＠cmccarthy) 07 Jul '23

07 Jul '23

-- v2: vkd3d-shader/dxil: Read function bodies. vkd3d-shader/dxil: Read numeric constants. vkd3d-shader/dxil: Read global function declarations. vkd3d-shader/dxil: Validate the module format version. vkd3d-shader/dxil: Read the value symbol table. vkd3d-shader/dxil: Read the type table. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/259

3 13

[PATCH 0/5] MR3257: mshtml: TextRange ref leak fixes.
by Gabriel Ivăncescu (＠insn) 07 Jul '23

07 Jul '23

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

3 6

[PATCH v2 0/1] MR261: vkd3d-shader: Add compiler option to specify matrix majority.
by Nikolay Sivov (＠nsivov) 07 Jul '23

07 Jul '23

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: vkd3d-shader: Add compiler option to specify matrix majority. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/261

4 9

[PATCH v2 0/1] MR3222: localspl: Add workaround for old versions of cups.h
by Fabian Maurer (＠DarkShadow44) 07 Jul '23

07 Jul '23

Recent versions of cups.h have HTTP_STATUS_CONTINUE as enum, so defining it doesn't hurt -- v2: localspl: Add workaround for old versions of cups.h https://gitlab.winehq.org/wine/wine/-/merge_requests/3222

4 6

[PATCH 0/6] MR3261: Remove DECLSPEC_HIDDEN macro various dlls.
by Alistair Leslie-Hughes (＠alesliehughes) 07 Jul '23

07 Jul '23

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

4 8

Re: [PATCH v4 0/6] MR3165: dxgi: Introduce a worker thread for each D3D12 swapchain (first part).
by Giovanni Mascellani (＠giomasce) 07 Jul '23

07 Jul '23

On Tue Jul 4 13:08:35 2023 +0000, Henri Verbeet wrote: > > The part that doesn't thrill me is the fact that DXGI still directly > accesses the VkQueue object, which I tend to see as an internal > implementation detail to vkd3d. On the other hand it's nice that we > don't need new API from vkd3d (even if, in the future, we were to need > something other than vkQueueSubmit() and vkQueuePresentKHR()). > For what it's worth, it was a fairly explicit design decision early on > to expose the underlying Vulkan objects for d3d12 devices and command > queues, as well as to allow the creation of d3d12 resources on top of > existing Vulkan images, for the purpose of interoperation with other > Vulkan code. I.e., the idea is that it should be possible to integrate > vkd3d into a larger Vulkan application to draw some parts using the > d3d12 API, while everything else is drawn using Vulkan. > The internal queueing of command queue operations on the vkd3d level is > unfortunate in that regard; ideally we just wouldn't do that. This MR > could probably do a better job of explaining why we need to do that in > some cases, and what kind of command queue operation sequences could > result in out-of-order presentation. > If we're going to need to introduce a DXGI worker thread anyway, could > we just make vkd3d_acquire_vk_queue() block until there are no longer > any operations queued? We already somewhat discussed that internally, but for the benefit of public archival the behavior of `vkd3d_acquire_vk_queue()` and `vkd3d_release_vk_queue()` was documented in https://gitlab.winehq.org/wine/vkd3d/-/commit/b2a1f6b5e4f59fbc7f91ada7e5656…. I'll implement the behavior recommended there in my next MR. The reason why it was decided to recommend to explicitly synchronize with an `ID3D12Fence` instead of making `vkd3d_acquire_vk_queue()` block until the queue is empty is because it is believed that the application is better than vkd3d at knowing how long it really makes sense to wait before actually acquiring the queue. In other words, `vkd3d_acquire_vk_queue()` doesn't know which queued operations are really required to be serialized with the queue acquisition. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3165#note_38301

1 0

2025

2024

2023

2022

wine-gitlab July 2023