On 2024-10-21 11:20, Derek Lesho wrote: > On 10/21/24 11:08, Michel Dänzer wrote: > >> 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? >> >> > Unfortunately that wouldn't be quite enough, as linux-mmap's MAP_32BIT flag > only uses the first 2 GBs of address space, and we need to allow for the use > of all 4GB of address space for apps which have activated the LAA (large > address-space aware) flag in their executable.
And Wine's solution for this can't be implemented in Mesa? -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
