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

[Paul Gofman]

On 10/22/24 18:03, Derek Lesho wrote:
>
> 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.
>
I am afraid accessing Wine internal mapping ranges is not a feasible 
option. One thing that it is very internal Wine detail and can change 
any moment, that gets evolved and modified from time to time for 
improving Windows compatibility and optimization purposes. Besides the 
access to that inside Wine is synchronized inside Wine (also involving 
signal masking). TLDR, interfering with that from the outside doesn't 
look possible.