Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

Hey Timur,

This is actually what Wine has traditionally done, the problem is that 
we are moving forward to a new implementation for running 32-bit Windows 
apps, where all of Wine's ELF code is 64-bit, and interacts with the 
host as a normal 64-bit app. In order to use a 32-bit driver in this 
context, we'd have to somehow switch the codepage back to 32-bit on the 
unix side again, and then manually load second copies of mesa and its 
dependencies like glibc, which would be a lot of effort.

I hope this clears things up, let me know if not

On 10/19/24 17:47, Timur Kristóf wrote:
> Hello Derek,
>
> As I am not working on GL, I don't have anything to contribute to the
> discussion, but I just have a question out of curiosity: what's wrong
> with simply using a driver that is compiled for 32-bit?
>
> Best regards,
> Timur
>
> On Fri, 2024-10-18 at 23:55 +0200, Derek Lesho wrote:
>> Hey everyone 👋,
>>
>> I'm Derek from the Wine project, and wanted to start a discussion
>> with
>> y'all about potentially extending the Mesa OGL drivers to help us
>> with a
>> functionality gap we're facing.
>>
>> Problem Space:
>>
>> In the last few years Wine's support for running 32-bit windows apps
>> in
>> a 64-bit host environment (wow64) has almost reached feature
>> completion,
>> but there remains a pain point with OpenGL applications: Namely that
>> Wine can't return a 64-bit GL implementation's buffer mappings to a
>> 32
>> bit application when the address is outside of the 32-bit range.
>>
>> Currently, we have a workaround that will copy any changes to the
>> mapping back to the host upon glBufferUnmap, but this of course is
>> slow
>> when the implementation directly returns mapped memory, and doesn't
>> work
>> for GL_PERSISTENT_BIT, where directly mapped memory is required.
>>
>> A few years ago we also faced this problem with Vulkan's, which was
>> solved through the VK_EXT_map_memory_placed extension Faith drafted,
>> allowing us to use our Wine-internal allocator to provide the pages
>> the
>> driver maps to. I'm now wondering if an GL equivalent would also be
>> seen
>> as feasible amongst the devs here.
>>
>> Proposed solution:
>>
>> As the GL backend handles host mapping in its own code, only giving
>> suballocations from its mappings back to the App, the problem is a
>> little bit less straight forward in comparison to our Vulkan
>> solution:
>> If we just allowed the application to set its own placed mapping when
>> calling glMapBuffer, the driver might then have to handle moving
>> buffers
>> out of already mapped ranges, and would lose control over its own
>> memory
>> management schemes.
>>
>> Therefore, I propose a GL extension that allows the GL client to
>> provide
>> a mapping and unmapping callback to the implementation, to be used
>> whenever the driver needs to perform such operations. This way the
>> driver remains in full control of its memory management affairs, and
>> the
>> amount of work for an implementation as well as potential for bugs is
>> kept minimal. I've written a draft implementation in Zink using
>> map_memory_placed [1] and a corresponding Wine MR utilizing it [2],
>> and
>> would be curious to hear your thoughts. I don't have experience in
>> the
>> Mesa codebase, so I apologize if the branch is a tad messy.
>>
>> In theory, the only requirement from drivers from the extension would
>> be
>> that glMapBuffer always return a pointer from within a page allocated
>> through the provided callbacks, so that it can be guaranteed to be
>> positioned within the required address space. Wine would then use
>> it's
>> existing workaround for other types of buffers, but as Mesa seems to
>> often return directly mapped buffers in other cases as well, Wine
>> could
>> also avoid the slowdown that comes with copying in these cases as
>> well.
>>
>> Why not use Zink?:
>>
>> There's also a proposal to use a 32-bit PE build of Zink in Wine
>> bypassing the need for an extension; I brought this to discussion in
>> this Wine-Devel thread last week [3], which has some arguments
>> against
>> this approach.
>>
>>
>> If any of you have thoughts, concerns, or questions about this
>> potential
>> approach, please let me know, thanks!
>>
>> 1:
>> https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation
>>
>> 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663
>>
>> 3: https://marc.info/?t=172883260300002&r=1&w=2
>>