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

[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: 
>> 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
>>
>