Access to graphics memory mappings on upcoming WOW64 implementation

[Derek Lesho]

On 25.04.22 12:38, Derek Lesho wrote:
>
> On 25.04.22 01:31, Zebediah Figura wrote:
>> On 4/24/22 21:18, Derek Lesho wrote:
>>> Hi All,
>>>
>>> In the wake of the new WOW64 implementation (recent explanation 
>>> [1]), there has been discussion in informal channels about how to we 
>>> are going to handle pointers to mapped graphics resource memory 
>>> which we receive from the graphics API, as the possibility exists 
>>> that it will fall outside of the 32-bit address space.
>>>
>>> Over time, a few creative solutions have been proposed and 
>>> discussed, with a common theme being that we need changes in either 
>>> the kernel or the graphics drivers to do this properly. As we 
>>> already know the requirements for a solution to this problem, I 
>>> think it would be responsible to hash this out now and then work 
>>> with the relevant project maintainers earlier as to avoid blocking 
>>> work on the wine side too long and to possibly allow more users to 
>>> test the new path earlier.
>>
>> Thank you for starting this conversation! I agree with all of these 
>> points. WoW64 emulation is still a long way off, if it'll even happen 
>> by default on platforms other than Mac, but nevertheless this is 
>> something we should look into supporting sooner than later.
>>
>> It would probably be good to start a dri-devel/mesa-dev thread to 
>> discuss this as well.
> Agreed, I just filed a feature request at the Vulkan-Docs repo so that 
> we can also hear the opinions of those working on non-mesa drivers 
> like NV.
>
> https://github.com/KhronosGroup/Vulkan-Docs/issues/1832

It looks like Jason Ekstrand drafted two extensions for us here, and 
would like to know our opinion on which approach would be the best for 
us, as he is even willing to write the extension text for us.

As explained in the thread, the two approaches are

1) Introduce a MAP_32BIT flag to vkMapMemory which the driver would 
forward to mmap.

2) Read the ppData parameter used to return the memory mapping as a 
suggestion for the mapping location, similar to how BaseAddress is used 
NtAllocateVirtualMemory.

I think the more flexible second solution be most ideal for us, as it 
allows us to handle the LAA case, but what do you guys think?