Access to graphics memory mappings on upcoming WOW64 implementation

[Alexandre Julliard]

Derek Lesho <dlesho at codeweavers.com> writes:

> 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?

I don't think that's sufficient, because there's no way to ensure that
the address that we picked is still available.

What we would want is to have it map into already reserved memory, which
would require the driver to use our specified address with MAP_FIXED.
Also it would have to avoid calling munmap() on free and let us take
care of remapping anonymous memory.

-- 
Alexandre Julliard
julliard at codeweavers.com