http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #270 from Pierre-Loup Griffais bugs.winehq.org@plagman.net 2012-12-21 16:22:03 CST --- (In reply to comment #269)
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.
ARB_map_buffer_range works great, I never implied otherwise. It just isn't well-suited for dynamic buffer updates when you force-enable the multi-threaded driver. Keep in mind I'm not trying to fix an NVIDIA performance problem here, there isn't one that I know of. I'm showing you a way to get more performance by using a combination of APIs and functionality that maps better to this use case. You're acting like I'm trying to sneak code into Wine to work around broken driver design. I would definitely recommend using ARB_map_buffer_range for other use cases, where it makes sense.
(In reply to comment #269)
I'm not sure why you'd want the CS to be involved at all, MapBuffer*() should essentially be a wrapper around ioremap_*().
Yes, that's "essentially" what it does. However it does return a value immediately, so it has ensure any GL commands in-flight between the main and worker threads are fully completed before it can be processed. I'll add that before you can perform the mapping ioctl, you have to figure out which context is current, which buffer name is bound, resolve that name, figure out what's the state of the buffer, where it's stored, what rendering is in flight, validate the access modes and plenty of other stuff.