http://bugs.winehq.org/show_bug.cgi?id=55981
Trass3r trass3r@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trass3r@gmail.com
--- Comment #20 from Trass3r trass3r@gmail.com --- (In reply to Zeb Figura from comment #3)
we'll need extensions that let us control mapped buffer placement. One is in progress (and possibly even done?) for Vulkan
https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_EXT_map_m...
(In reply to Shmerl from comment #15)
GL_MESA_placed_allocation. Not sure how far that progressed though, it didn't get to Khronos it seems.
https://gitlab.winehq.org/dlesho/wine/-/compare/master...wow64_placed_alloc?...
(In reply to Matthew from comment #17)
The logs contained a fixme "Doing a copy of a mapped buffer (expect performance issues)", which I traced to unix_wgl.c in the opengl32 dll
Exactly. I took a perf trace of DK2 and most of the time was spent copying 512KB of streaming buffer back and forth just for a few vertices for every DrawIndexedPrimitive.
From what I can tell it's a combination of several problems.
It uses the glMapBufferRange code path: https://github.com/wine-mirror/wine/blob/master/dlls/wined3d/context_gl.c#L2... Because ARB_buffer_storage is not supported in wow64, see the previous comment and https://gitlab.winehq.org/etaash.mathamsetty/wine/-/compare/master...cursed-...
It always maps the whole streaming buffer even though it tracks the changed parts and flushes them correctly: https://gitlab.winehq.org/wine/wine/-/commit/793ac83d5b7fc0bc440714b218d607a...
wow64_map_buffer does skip the copy if you use GL_MAP_INVALIDATE_* flags but wined3d fails to properly set these flags.
But then you still have the copy at unmap which happens cause it doesn't track the flush range calls done by wined3d.
https://github.com/wine-mirror/wine/compare/master...Trass3r:wine:map-buffer...