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.
