On 2024-10-18 23:55, 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. Does this really require a callback, or could e.g. a "keep application-visible mappings within 32-bit range" context flag work?
-- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
