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

[Timur Kristóf]

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
>