March 2024 - wine-gitlab

[PATCH v5 0/2] MR711: vkd3d-shader/ir: Introduce a better CFG structurizer, part 6.
by Giovanni Mascellani (＠giomasce) 18 Mar '24

18 Mar '24

~~This applies on top of !704, the last two commits belong here.~~ Here we finally emit the structured program, replacing the older simple structurizer. The advantage of the new structurizer is that the CFG if statically described in the generated program, without having to trace the value of a variable. Upcoming MRs will make the CFG even simpler, easier to read and hopefully to optimize for downstream compilers. -- v5: vkd3d-shader/ir: Emit multilevel jumps in the structured program. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/711

4 5

[PATCH v3 0/6] MR5322: server: Clear queue QS_RAWINPUT if get_rawinput_buffer got everything.
by Rémi Bernon (＠rbernon) 18 Mar '24

18 Mar '24

-- v3: server: Process internal messages when checking queue status. server: Check for internal hardware messages before others. win32u: Use a structure to pass peek_message arguments. server: Send WM_WINE_SETCURSOR message only when necessary. server: Send WM_WINE_CLIPCURSOR message only when necessary. winex11: Accept key and mouse events with QS_RAWINPUT. https://gitlab.winehq.org/wine/wine/-/merge_requests/5322

2 7

[PATCH v2 0/5] MR5322: server: Clear queue QS_RAWINPUT if get_rawinput_buffer got everything.
by Rémi Bernon (＠rbernon) 18 Mar '24

18 Mar '24

-- v2: server: Do not use QS_RAWINPUT for internal hardware messages. server: Clear queue QS_RAWINPUT if get_rawinput_buffer got everything. server: Process internal messages when checking queue status. server: Check for internal hardware messages before other messages. win32u: Use a structure to pass peek_message arguments. https://gitlab.winehq.org/wine/wine/-/merge_requests/5322

5 13

[PATCH 0/8] MR5339: mfplat/mediatype: More VIDEOINFOHEADER2 to IMFMediaType mappings.
by Rémi Bernon (＠rbernon) 18 Mar '24

18 Mar '24

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

3 10

[PATCH v25 0/9] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon (＠rbernon) 18 Mar '24

18 Mar '24

First part of Proton shared memory series. The full branch can be seen at https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories. -- v25: win32u: Use the desktop shared data for GetCursorPos. server: Move the last cursor time to the desktop session object. server: Move the cursor position to the desktop session object. win32u: Open desktop shared objects from session mapping. server: Return the desktop object info in get_thread_desktop. server: Allocate shared session object for desktops. win32u: Open the global session shared mapping. include: Add ReadNoFence64 inline helpers. server: Create a global session shared mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

3 36

[PATCH 0/1] MR5340: maintainers: Remove MF GStreamer section.
by Rémi Bernon (＠rbernon) 18 Mar '24

18 Mar '24

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

2 1

[PATCH v6 0/3] MR5060: win32u, explorer, winex11.drv: Restore display settings on process exit.
by Anton Baskanov (＠baskanov) 18 Mar '24

18 Mar '24

-- v6: explorer: Restore display settings on process exit. winex11.drv: Process RRNotify events in xrandr14_get_id. user32/tests: Test that display settings are restored on process exit. https://gitlab.winehq.org/wine/wine/-/merge_requests/5060

3 48

[PATCH v15 0/6] MR631: Draft: vkd3d: Implement UpdateTileMappings().
by Conor McCarthy (＠cmccarthy) 18 Mar '24

18 Mar '24

-- v15: vkd3d: Support aliased tile binding if available. vkd3d: Implement ID3D12CommandQueue::UpdateTileMappings() for textures. vkd3d: Implement ID3D12CommandQueue::UpdateTileMappings() for buffers. vkd3d: Pre-bind sparse texture mip tails. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/631

2 6

[PATCH v14 0/6] MR631: Draft: vkd3d: Implement UpdateTileMappings().
by Conor McCarthy (＠cmccarthy) 18 Mar '24

18 Mar '24

-- v14: vkd3d: Support aliased tile binding if available. vkd3d: Implement ID3D12CommandQueue::UpdateTileMappings() for textures. vkd3d: Implement ID3D12CommandQueue::UpdateTileMappings() for buffers. vkd3d: Pre-bind sparse texture mip tails. tests/d3d12: Add a test for freeing underlying memory of a reserved resource. tests/d3d12: Add tests for UpdateTileMappings(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/631

2 6

[PATCH 0/2] MR5338: wined3d: Require EXT_framebuffer_object.
by Zebediah Figura (＠zfigura) 18 Mar '24

18 Mar '24

This is the first of a couple of patch sets which intend to impose some new requirements on GL support. In total I intended to submit patches to require these things: * EXT_framebuffer_object * ARB_texture_non_power_of_two (including WINED3D_GL_NORMALIZED_TEXRECT) * GLSL 1.20 And, unless demand to the contrary is demonstrated, to remove the code paths that care about their absence. This means that the "OffscreenRenderingMode" setting, the ARB shader backend, and all non-GLSL fixed-function pipeline backends will be removed. All of these extensions are at least 17 years old at the current date. -- Some explanation may be warranted. In general Wine is reticent to impose heavy requirements on users' software or hardware, and when it comes to Direct3D we have been especially conservative in this respect. Critically, this is not necessarily a matter of being realistically concerned about hardware or software still in use—although we do tend to be more conscious than most projects about some users' long-term support requirements—but more importantly that we do not waste time removing features just because they are believed to be obsolete. Even where related code is being touched, and hence removing code may seem helpful, it is often easy and generally better to abstract away and "quarantine" that code. The ARB shader backend, for example, is very much quarantined in this way; it is not difficult to modify the GLSL backend and leave the ARB backend alone. With that said, as far as the listed extensions are concerned, there are some reasons I would like to impose these requirements anyway. * In the first case, not all code can be easily "quarantined". Support for ORM_BACKBUFFER, in particular, is very invasive, and affects a large number of disparate places in small ways, rather than being a single alternate path. Support for NP2 fixup is similar, although perhaps a bit less invasive than ORM_BACKBUFFER. * Even with code that can be quarantined, there are some smaller, but I believe nonnegligible, costs to keeping that code around. Speaking in concrete terms so as to be more understandable, if I wish to refactor the way states are tracked and invalidated, I need to do some work to either refactor other backends the same way as the GLSL backend (e.g. 5126), or adjust the quarantine so that the old path is kept around just for quarantined code. Doing the latter has a tendency to build up and make the code difficult to follow. A new contributor can easily get led down the wrong path that way. * Somewhat relatedly, when some functionality or internal helper needs to be fixed, a contributor (and the maintainer) needs to then either spend time fixing *every* backend, or know that some backends don't matter and ignore them [if ignoring is even feasible for a given change]. The latter can be difficult to discover, especially for a new contributor, and even then it takes time—and, in a malleable sense, maintenance burden—to look through code and confirm that it doesn't matter. To be clear, this is not meant as rationale to start removing anything and everything. As with all things, these are tradeoffs, between all of the above reasons to keep or remove any given code. The three listed GL extensions are the only three which I believe, at the moment, that there is enough utility in requiring, and little enough reason to keep. This was a matter of some internal discussion among Direct3D contributors. However, there is not really a consensus — or at least not an enthusiastic consensus — that this is desirable. The above is an attempt to summarize the concerns and justify why I personally think this is a good idea. But it's a difficult decision, and that's at least in part because this code is the best translation layer from old Direct3D to *contemporaneous* GL, and it's sad to see that go. At the same time, in the world of version control, no code is ever truly gone. Hence perhaps the most simple argument to make is that if we are really going to *maintain* this code, that will take extra work—work which at this point I really would rather not do—and if we are not going to maintain it, then we're not offering any more utility than an actual git archive. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5338

3 3

2025

2024

2023

2022

wine-gitlab March 2024