http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #269 from Henri Verbeet hverbeet@gmail.com 2012-12-21 15:53:02 CST --- (In reply to comment #268)
(In reply to comment #267)
D3D "dynamic" buffers end up using either GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT on glMapBufferRange(), and shouldn't require synchronization with the command stream at all; it's the application's responsibility to ensure all accesses are safe.
It's still a synchronous API that needs to return a pointer immediately, though, so it stalls the CPU command stream between the main and worker thread in the driver. Which, in turn, can introduce GPU starvation.
I'm not sure why you'd want the CS to be involved at all, MapBuffer*() should essentially be a wrapper around ioremap_*().
You'd think the performance gains I demonstrated (and that Stefan observed in real-world usage) would be justification enough.
Well, no.
if performance problems are uncovered (if any). It certainly seems like a better approach than trying to fix drivers to optimize paths for usage patterns that don't make sense at the cost of introducing overhead for usage patterns that do.
If you really feel you can't possibly make ARB_map_buffer_range work correctly, you probably shouldn't expose the extension at all. The fallback path we currently have for that would need some improvements, but that shouldn't be much of a problem.