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 >
