<div dir="auto">Is there a way for drivers to change the semantics of memory mappings to make mremap work? <div dir="auto"> </div><div dir="auto">Marek</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 24, 2024, 07:08 Derek Lesho <<a href="mailto:dlesho@codeweavers.com">dlesho@codeweavers.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In my last mail I responded to this approach all the way at the bottom, so it probably got lost: mremap on Linux as it exists now won't work as it only supports private anonymous mappings (in conjunction with MREMAP_DONTUNMAP), which GPU mappings are not. Am 10/24/24 um 01:06 schrieb James Jones: > That makes sense. Reading the man page myself, it does seem like: > > -If the drivers can guarantee they set MAP_SHARED when creating their > initial mapping. > > -If WINE is fine rounding down to page boundaries to deal with > mappings of suballocations and either using some lookup structure to > avoid duplicate remappings (probably needed to handle unmap anyway per > below) or just living with the perf cost and address space > overconsumption for duplicate remappings. > > -If mremap() preserves the cache attributes of the original mapping. > > Then no GL API change would be needed. WINE would just have to do an > if (addrAbove4G) { mremapStuff() } on map and presumably add some > tracking to perform an equivalent munmap() when unmapping. I assume > WINE already has a bunch of vaddr tracking logic in use to manage the > <4G address space as described elsewhere in the thread. That would be > pretty ideal from a driver vendor perspective. > > Does that work? > > Thanks, > -James > > On 10/23/24 06:12, Christian König wrote: >> I haven't read through the whole mail thread, but if you manage the >> address space using mmap() then you always run into this issue. >> >> If you manage the whole 4GiB address space by Wine then you never run >> into this issue. You would just allocate some address range >> internally and mremap() into that. >> >> Regards, >> Christian. >> >> Am 22.10.24 um 19:32 schrieb James Jones: >>> This sounds interesting, but does it come with the same "Only gets >>> 2GB VA" downside Derek pointed out in the thread fork where he was >>> responding to Michel? >>> >>> Thanks, >>> -James >>> >>> On 10/22/24 07:14, Christian König wrote: >>>> Hi guys, >>>> >>>> one theoretical alternative not mentioned in this thread is the use >>>> of mremap(). >>>> >>>> In other words you reserve some address space below 2G by using >>>> mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) and >>>> then use mremap(addr64bit, 0, length, MREMAP_FIXED, reserved_addr). >>>> >>>> I haven't tested this but at least in theory it should give you a >>>> duplicate of the 64bit mapping in the lower 2G of the address space. >>>> >>>> Important is that you give 0 as oldsize to mremap() so that the old >>>> mapping isn't unmapped but rather just a new mapping of the >>>> existing VMA created. >>>> >>>> Regards, >>>> Christian. >>>> >>>> >>>> Am 18.10.24 um 23:55 schrieb Derek Lesho: >>>>> 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: >>>>> <a href="https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation</a> >>>>> >>>>> >>>>> 2: <a href="https://gitlab.winehq.org/wine/wine/-/merge_requests/6663" rel="noreferrer noreferrer" target="_blank">https://gitlab.winehq.org/wine/wine/-/merge_requests/6663</a> >>>>> >>>>> 3: <a href="https://marc.info/?t=172883260300002&r=1&w=2" rel="noreferrer noreferrer" target="_blank">https://marc.info/?t=172883260300002&r=1&w=2</a> >>>>> >>>> >> </blockquote></div>