Access to graphics memory mappings on upcoming WOW64 implementation

[Zebediah Figura]

On 4/25/22 03:48, Georg Lehmann wrote:
> 
> 
> 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.

Right, I should clarify, the problem isn't supporting coherent memory, 
but rather device-visible coherent memory.

Unfortunately, it seems that Vulkan requires this as well. From the 
Vulkan 1.0.211 specification § 12.6, regarding 
vkGetBufferMemoryRequirements():

     If buffer is a VkBuffer not created with the 
VK_BUFFER_CREATE_SPARSE_BINDING_BIT bit set, or if image is linear 
image, then the memoryTypeBits member always contains at least one bit 
set corresponding to a VkMemoryType with a propertyFlags that has both 
the VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT bit and the 
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT bit set. In other words, mappable 
coherent memory can always be attached to these objects.

Obviously tracking things manually will hurt performance in some 
applications, but I mention it since we may (or may not!) need a 
fallback, in order to guarantee we have *some* way of correctly 
emulating WoW64 maps. Personally I think it's better not to require 
WoW64 emulation in such cases.

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

Interesting. What extensions do these correspond to?