Access to graphics memory mappings on upcoming WOW64 implementation
Derek Lesho
dlesho at codeweavers.com
Sun Apr 24 21:18:49 CDT 2022
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.
The solutions which I've seen laid out so far:
- Use the mremap(2) interface, allowing us to duplicate the mapping we
receive into the 32-bit address space. This solution would match what
is already done for Crossover Mac's 32on64 support using Mac's
mach_vm_remap functionality [2]. However, right now it is not possible
to use the MREMAP_DONTUNMAP flag with mappings that aren't private and
anonymous, which rules out there use on mapped FDs from libdrm. Due to
this, a kernel change would be necessary.
Pro: A uniform solution across all APIs, which could help in the
future with any unforeseen need to access host-allocated memory in
32-bit windows code.
Cons: Requires a kernel change, which of all the options may take
the longest to get up-streamed and in the hands of users.
- Work with Khronos to introduce extensions into the relevant APIs
enabling us to tell drivers where in the address space we want resources
mapped.
Pro: Wouldn't require going around the backs of the driver,
resulting in a more hardened solution. (Out there, but what if a
creative driver returns a mapping without read or write permission and
handles accesses through a page fault handler?)
Cons: The extension would have to be implemented by each individual
vendor for every relevant API. This would implicitly drop support for
those with cards whose graphics drivers are no longer being updated.
- Hook the driver's mmap call when we invoke memory mappings function,
overriding the address to something in the 32-bit address space.
Pro: Unlike the other solutions, this wouldn't require any
changes to other projects, and shares the advantage of the first solution.
Cons: Susceptible to breakage if the driver uses their own
mapping mechanism separate from mmap. (Custom IOCTL, CPU driver
returning something from the heap)
1: https://www.winehq.org/pipermail/wine-devel/2022-April/213677.html
2: https://www.codeweavers.com/crossover/source - see function
`remap_memory` in `wine/dlls/winemac.drv/opengl.c`
More information about the wine-devel
mailing list