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

[Derek Lesho]

Am 10/21/24 um 11:35 schrieb Michel Dänzer:

> And Wine's solution for this can't be implemented in Mesa?

I think this might actually be possible: In order to accomplish this 
Wine essentially keeps calling mmaps with addresses in its range until 
it finds a free spot. It of course is able to already skip addresses it 
itself has mapped, which spares needlessly calling of mmap for nearly 
every possible page before finding one in cases where the address space 
is almost filled up.

The two practical problems here would be that Mesa wouldn't have access 
to Wine's mapping table without additional plumbing, and allocating GPU 
memory, already a slow operation, might become even slower. (If wanted I 
can try drafting this solution when I get time to see, but I'm swamped 
with Uni work atm).

The other problem is that Wine also has a system of reserved ranges, 
where it reserves certain important page ranges on setup so that no 
other libraries steal them from Wine. As far as I can see in Vanilla 
Wine this isn't a huge portion of the address-space, but if I remember 
correctly there have been considerations in the past to expand these 
ranges to speed up virtual memory allocation instead of working through 
mmap.

And then of course there's the question: Do y'all want to have all this 
allocation complexity in Mesa, when you're have the Wine library sitting 
right next to you able to do it in a way guaranteed to work?


Am 10/21/24 um 16:33 schrieb Jose Fonseca:

> I see a few downsides with the proposed callback:
> - feels like a solution too tailored for WINE
> - there's a layering violation: the application suddenly takes the 
> driving seat for a thing deep down in the GL driver
> so I fear Mesa community might regret it doing, and once WINE supports 
> there would be outcry if to go back.
Yeah, I'm sensible to this critic, and I also would rather a more 
surface level extension if possible, but it seems to me the troubles 
with the GL model prohibit it. Also, I would counter that the driver 
relying on Wine for what is effectively a glorified mmap most likely 
won't cause restrictions or pains in the future.

> IIUC the problem at hand, another way to go about this would be an 
> extension that allows applications to get a malloc'ed/valloc'ed memory 
> exposed to the GPU as a GL buffer object.
I'll defer to others more knowledgeable than me on the viability of 
using host imported memory, but I know we have a fallback path in 
Winevulkan using the Vulkan external_host_memory extension, which was 
known to be slower than the more direct placed memory solution. I'm 
cc'ing Jacek (I hope you don't mind 😅), as they ended up implementing 
both Wine's external_host_memory path and placed_memory path for our 
WoW64 support, and might have more details on the differences here.

Am 10/21/24 um 23:21 schrieb James Jones:

> All that said, I don't love the idea of callbacks either. Callbacks in 
> general are tough to specify and use robustly, and hence should be a 
> last resort. E.g., this particular callback might sometimes come from 
> the application thread, and sometimes come from some separate 
> driver-managed thread. It's hard to validate that all applications can 
> handle that properly and wouldn't do something crazy like rely on 
> their own TLS data in the callback or try to call back into OpenGL 
> from the callback and deadlock themselves, even if these are clearly 
> specified as an unsupported actions. 
Yeah, I agree it should be a last resort solution. In my draft Wine 
implementation, I marshal all calls from driver threads back to a thread 
created by Wine for the allocation to work, but having to then define 
this in terms of a general extension is quite ugly... I'm curious if 
there's a consensus here that Mesa would rather call into a custom Wine 
mmap when available, instead of exposing a general extension for other 
applications to shoot themselves in the foot with. If so, I hope 
Julliard or someone in that area could chime in what they think of the idea.


Am 10/22/24 um 11:15 schrieb Jose Fonseca:

> So, it sounds like something like an OpenGL equivalent of
> VK_EXT_map_memory_placed would be more palatable?
Yes this is the goal, if a similarly straightforward extension for GL is 
possible I think everyone would be for it, but I'm not sure that's the 
case. To this topic, maybe take a look at the wine-devel thread about 
some potential options I started a few weeks ago, where we discuss 
potential callback-less alternatives. This link should have relevant 
context: https://marc.info/?l=wine-devel&m=172894900019588&w=2


Am 10/22/24 um 16:14 schrieb Christian König:

> 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. 
This unfortunately won't work for the reason that mremap on Linux only 
works on anonymous private pages, which GPU mappings are not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20241023/9d346a38/attachment-0001.htm>