Access to graphics memory mappings on upcoming WOW64 implementation

[Georg Lehmann]

On 25.04.22 07:31, Zebediah Figura wrote:
> - We can emulate mappings for everything except coherent memory by 
> manually implementing mapping functions with a separate sysmem location. 
> We can implement persistent mappings this way, too, by copying on a 
> flush, but unfortunately we can't expose GL_ARB_buffer_storage without 
> coherent mappings.
> 
>    [Fortunately d3d doesn't require coherent memory or 
> ARB_buffer_storage, and the Vulkan backend doesn't require coherent 
> memory for map acceleration. The GL backend currently does, but could be 
> made not to. We'd have to add a private extension to use 
> ARB_buffer_storage while not actually marking any maps as coherent. Of 
> course, d3d isn't the only user of GL or Vulkan, and unfortunately 
> ARB_buffer_storage is core in 4.3, so I'm sure there are GL applications 
> out there that rely on it...]
> 

Obvious performance issues of this solution aside, many Vulkan 
applications require coherent memory. There is also this requirement in 
the vk spec:

 > There *must* be at least one memory type with both the 
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT and 
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT bits set in its propertyFlags.


>    I think we can actually emulate coherent memory as well, by tracking 
> resource bindings and manually flushing on draws. That's a little 
> painful, though.
> 

This is not possible in Vulkan, especially with newer features like 
buffer device address or update after bind.

> - Crazy idea: On Linux, parse /proc/self/maps to allow remapping 
> non-anonymous pages. Combined with mremap(2) or manual emulation, this 
> allows mapping everything except for shared anonymous pages [and I can't 
> imagine that a GPU driver would use those, especially given that the 
> only way to make use of the SHARED flag is fork(2)].
> 
> ἔρρωσθε,
> Zeb
>