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.