Looking at it a bit it seems to me that the [GL_AMD_pinned_memory](https://registry.khronos.org/OpenGL/extensions/AMD/AMD_pinned_memory.txt) extension could be used to do what we want. It's implemented in Mesa (including for Intel), but apparently not on Nvidia.
Good point, thanks. It does seem possible to use that extension, but I think we also need to support Nvidia. We could maybe have it as an alternative, though I’m not sure there are cases where it would actually help (that is, cases where the extension is available but a sufficient Vulkan driver isn’t).
It also appears to force the driver to use system memory for the buffer, while with Vulkan we can control and tune that ourselves.
If we have Vulkan then it would probably be better to use the Vulkan D3D backend.
Yes, ideally we’d always use Vulkan for D3D, I believe that’s a work in progress. While D3D performance is the most visible effect of the lack of persistent memory support, I think we'd still want it for pure OpenGL applications as well.
For native OpenGL games, although I don't know any which suffer from the same performance issues as WineD3D
Note that it’s not just about performance, we’re also missing features that some applications may require. Unlike WineD3D, which has a fallback, persistent mappings can be a required feature for an application. We also currently need to limit the OpenGL version, which may itself be a requirement.
the Zink route is perhaps another choice.
Yes, that’s an interesting alternative. With PE Zink we wouldn’t need any of that. However, I don’t think we can bundle Zink with Wine itself, so it wouldn’t be an out-of-the-box solution.