wine-devel

5 participants
84370 discussions

Discussing paths forward for OpenGL mappings on Wow64
by Derek Lesho 13 Oct '24

13 Oct '24

Hi everyone, I'm creating this thread to start a discussion about how we want to complete GL support on Wow64, in the hopes that, if we want a MESA extension for this, we can get it to them sooner rather than later. The core of the problem is same that we faced for Vulkan: namely that host visible mappings from graphics APIs may be located above 32-bit memory, in which case we can't pass them to the application as is. In the current implementation that Rémi wrote a few years ago, we use a temporary buffer for glMapBuffer, and manually have to copy the data from it back to the real mapping on glUnmapBuffer. This solution works for most applications, but is slower than direct writes, and doesn't allow use of the GL_MAP_PERSISTENT_BIT glMapBuffer flag, where the application doesn't have to unmap the memory before usage by the API. Because of this problem, we can't support GL versions >= 4.4 in this path, which admittedly isn't a huge problem considering wined3d now supports Vulkan, but does rule out some native GL apps/games from running on the new path. I'll go over a few potential solutions: - "Just Use Zink": this idea has been floated for a while, and would be to use a PE build of Zink, the MESA gallium driver on top of Vulkan, which would then automatically make use of our VK_EXT_map_memory_placed integration in winevulkan and bypass the problem. Rémi has a branch with a draft solution for this [1] The advantage of approach is that it doesn't require any more extensions to any more APIs, but the disadvantage is that Wine would have to worry about keeping a separate version of Mesa up to date and support for building the required c++ components of mesa to its build system, as can be seen in the commits. - GL extension with placed memory allocation callback: In this case, Wine provides a map and unmap callback for the GL implementation to use in creating the pages it needs for GPU-mappings. In comparison to the PE Zink solution, we can continue to use system libraries, and maintain fast buffer IO, as long as the glMapBuffer implementation returns the mapped ptr directly. The main downside for this solution is of course the introduction of a new extension to the mostly dormant GL API, but here it would be possible to just use a VK_EXT_map_memory leveraging Zink like in the first solution, only this time on the Unix side. For this solution I've created a draft: Wine MR [2] Mesa Branch with Zink implementation [3] - glMapBuffer extension which we send our placed allocation: The idea here is that slightly extended glMapBuffer could be sent a flag to use Wine mapping, avoiding callbacks and targeting the problem where it manifests for Wine (when we get an address out of 32-bit space). This was briefly discussed on the LGD discord server, but it won't work well, due to the fact that a GL buffer is usually only a suballocation of a memory mapping, and often has already been assigned to another pool of memory by the time glMapMemory is called. Mesa would have to add a considerable sized implementation setting up custom-allocator pools, and be able to move buffers between them to implement this. - glBufferStorage extension to ease Mesa implementation: The next logical conclusion based on the problems of the last solution is that the Mesa implementation should get the information about any custom allocation at buffer creation time. The closest equivalent to this is the glBufferStorage entry, where we could create a new type of memory that we would ask the implementation to put the buffer in. For this solution we'd either have to implement custom memory allocator or introduce more API entries in order to allow the driver to convey to the application what size mappings it prefers. This would be very unwieldy, and wouldn't solve speed up the slow buffer copies for legacy buffers which don't use ARB_buffer_storage. - finally, going off the last possibility, if we're willing to create our own buffer allocator (we probably shouldn't, as the driver probably knows best), we could use the already existing EXT_external_objects extensions to import Vulkan memory objects, from which our allocator would allocate slices for the buffers. In glMapBuffer we would then return the Vulkan placed memory mapping. If I got anything wrong or overlooked anything, please let me know. If we decide on a solution that involves mesa, I would gladly then include the mesa-dev list to see if they have opinions for/against any of the proposals. Thanks, Derek 1: https://gitlab.winehq.org/rbernon/wine/-/tree/wip/just-use-zink 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 3: https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation

1 0

wined3d surface handle buffer overflow
by Fabian Maurer 11 Oct '24

11 Oct '24

Hello, I'm currently investigating a wined3d regression that leads to an assert - bug 57300. In short, there is memorys corruption in "d3d_device2_SwapTextureHandles" when copying a "global handle table" handle into the "device handle table". The "device handle table" is only 64 entries long, but the handle is bigger than that - writing out of bounds. As I see, it all surfaces get allocated into the global handle table. Then in d3d_device2_SwapTextureHandles they get copied into the device handle table. Once in "CreateStateBlock" and once in "EndStateBlock". The device handle table only contains the wined3d state block handle. If those assumptions are correct, I have a few questions: 1) Isn't there a risk of overriding the state block handle when swapping the texture with handle 1? 2) Why are the handles only copied, completely bypassing the ddraw_allocate_handle function? Doesn't this mess up the next call to "ddraw_allocate_handle"? A potential solution to the buffer overflow would be the increase the size of the table if the handle doesn't fit. But I don't know if that's the correct course of action, and I don't know what to do with the table size / count values. Or maybe there' something else wrong here that I'm not seeing, insights would be appreciated. Regards, Fabian Maurer

2 1

Upcoming vkd3d 1.14 release
by Henri Verbeet 10 Oct '24

10 Oct '24

Hi all, As previously announced, the planned release date for vkd3d 1.14 is November 21. That means the public API will become frozen two weeks from now on October 24, and features will be frozen after November 7. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 1.15 is February 19. Regards, Henri

1 0

Wine staging 9.19 release
by Alistair Leslie-Hughes 05 Oct '24

05 Oct '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.19 (354 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9_36: Add format description for X8L8V8U8 for format conversions. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

ntdll WRITECOPY dropped from staging
by Fabian Maurer 29 Sep '24

29 Sep '24

Hello, I noticed that the ntdll WRITECOPY changes got mostly dropped from staging in commit https://github.com/wine-staging/wine-staging/commit/ 16dce521242b3f4a52cd2c8799ce6fe464fac83c > The current state even after multiple iterations, the whole > WRITECOPY implemenet needs differently. Upstream will need to > do this. As I understand it, the implementation marks WRITECOPY pages as read-only on the unix side, handling the access violation and marking it as read-write afterwards. (Correct me if I'm wrong) What is wrong with the underlying concept, how should it be implemented properly? Regards, Fabian Maurer

2 1

Carry flag state after a system function call
by robert.ayrapetyan＠gmail.com 25 Sep '24

25 Sep '24

Hello, some legacy applications depend on the carry flag state after calling system functions. I've noticed that certain apps work correctly when using Wine installed from packages, but fail when Wine is built from sources. After investigating, I found that Wine from Debian packages is compiled with certain flags that stabilize ESP at the end of system function calls (e.g., sub ESP, 0x10), which, as a side effect, clears the carry flag, making the application happy. I tried using fno-omit-frame-pointer, but it generates lea instructions, which don't impact the carry flag. Has anyone else encountered same behavior? How frequently do older applications rely on the carry flag after system function calls? Also, which specific flags are used to compile the Wine version available in Debian packages?

5 5

Gitlab forks limit issue
by robert.ayrapetyan＠gmail.com 24 Sep '24

24 Sep '24

Hello, could you please let me know who I should contact to increase the quotas for my account (rayrapetyan) on https://gitlab.winehq.org/wine? I'm currently unable to fork Wine from https://gitlab.winehq.org/wine/wine/-/forks/new due to the following error: "Limit reached. You cannot create projects in your personal namespace. Contact your GitLab administrator." Also, would you consider accepting a merge request that modifies the GetDriveTypeA\W function to prioritize the mount manager? Let me know if this was discussed somewhere already.

2 3

Wine staging 9.18 release
by Alistair Leslie-Hughes 21 Sep '24

21 Sep '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.18 (361 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * ntdll-WRITECOPY Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Staging WRITECOPY fixes
by DodoGTA GT 20 Sep '24

20 Sep '24

Hello, I found a few issues with the WRITECOPY patch after wine-staging commit ae46f56f2cf20585387ff61cb7b36fd5f3d84837 which I managed to pretty much fix Patch 0003 is a replacement for the previous 0003 patch (apparently very early signal handling is still needed for some Unix-side ntdll functions); the added early argument checks could be replaced with NtCurrentTeb() instead (this would lead to 2 identical signal_init_process() calls though which may look weird) Patch 0004 updates the previous 0004 patch by removing a forgotten i386 compile-time check (which didn't make sense after that wine-staging commit) Patch 0005 is updated to fix conflicts because of the patch 0004 update (so it can be ignored for a manual rebase) Patch 0010 enables the WRITECOPY stuff by default (this is effectively a replacement for patches 0010 and 0011 without their hacky logic which really only works for Chromium-based applications); if this patch addition is too radical, then at least patches 0010 and 0011 should definitely be removed (hopefully there won't be another patch race anytime soon) Please note that patch 0003 also adds an extra ntdll-Syscall_Emulation dependency to fix a bad interaction with that patchset (also I should've sent this email at least a day earlier but hopefully some of these patches can get pushed) Thanks

1 0

[PATCH] Correction for Bug 52627 - Wishlist: add ohm symbol (greek capital Omega) to wine tahoma font
by MATHEUS VENTURINI BORTOLUZZI 20 Sep '24

20 Sep '24

Good afternoon, I've made a patch to fix the Ohm sign not appearing in LTSpice. I followed what was written in the discussion of Bug 52627 <https://bugs.winehq.org/show_bug.cgi?id=52627> - I copied the glyph for "OHM SIGN" and pasted it for "GREEK CAPITAL LETTER OMEGA" using FontForge. Since this is my first contribution to anything ever, I would greatly appreciate if someone could test this patch... Thank you in advance Matheus

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel