On Sun Sep 7 13:55:21 2025 +0000, Jacek Caban wrote:
We could create a memory object with Vulkan, import it into GL, and then handle map, unmap, and flush via Vulkan. That would be very invasive for arbitrary buffer objects, but for buffer storage objects, where the caller specifies the intention to map at creation time, it doesn’t seem too bad and is enough to support persistent mappings. In my testing, that alone brings the wined3d GL renderer performance on par with old wow64. Other usage patterns might benefit from a suballocator, but for the experiment I just created separate fds for each GL buffer storage.
Well, wined3d does its own suballocation. That's not true for arbitrary GL applications, though. I'm not saying we shouldn't commit such an approach, but we really should still be spending time on trying to get a generic extension.