Access to graphics memory mappings on upcoming WOW64 implementation

[Zebediah Figura]

On 4/25/22 16:51, Chris Robinson wrote:
>> - Hook the driver's mmap call when we invoke memory mappings function,
>> overriding the address to something in the 32-bit address space.
> 
> Similar to point 1, you can't be sure how the driver handles memory mapping.
> It could have preallocated memory that mapping simply returns a chunk of,
> meaning there wouldn't be an mmap call during the mapping function since it
> was done some time earlier. On 64-bit systems, the driver could also use a
> memory management style that's more efficient with a large address space
> instead of a smaller one. If you simply force 32-bit addresses on the driver,
> it could make the driver's memory management less efficient or be more
> wasteful with the already-limited 32-bit address space. Explicitly telling the
> driver you want 32-bit addresses for mapped memory would ensure the driver
> knows it needs to be more frugal with mappable memory.

This is a good point. We've already been bitten by drivers *not* being 
frugal with mappable memory even when the process is truly a 32-bit one. 
The Mac GL driver is the obvious offender here, but I've also seen this 
become a problem with radeonsi. So assuming we can get drivers to care 
in the first place, we should implement this to ensure that they can 
make that decision on WoW64 as well.

N.B. as stated elsewhere in this thread, I don't necessarily think this 
is the *only* option we should pursue—many of the solutions have 
benefits outside of the specific problem posed in Derek's original 
post—but it does currently seem like the ideal code path for GPU 
mappings specifically.