http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #271 from Henri Verbeet hverbeet@gmail.com 2012-12-22 00:44:38 CST --- (In reply to comment #270)
ARB_map_buffer_range works great, I never implied otherwise.
I'd consider stalling the CS on unsynchronized maps broken, since I think it defeats much of the point of having the extension in the first place. Thinking a bit more about it though, I guess not reporting ARB_map_buffer_range isn't really an option for you because it's core functionality in GL3 and later.
case. You're acting like I'm trying to sneak code into Wine to work around broken driver design.
Not really, but I am detecting a certain amount of "I'm from NVIDIA, trust me on this." and "Other drivers should be 'fixed' to behave the same way we do." in your arguments, and I don't think it's really helping them. I'm really just trying to figure out what the actual issue you're having with unsynchronized maps is.
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 don't think there's any such requirement in the GL spec, at least not for unsynchronized maps.
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.
Well, yes, but most of that applies to any GL call referencing a buffer object, including BufferSubData(). Are you implying that you've moved GL object name resolution (and related calls like DeleteBuffers()) into your worker thread as well? In that case you would indeed have to stall (well, sort of, you could probably avoid actually stalling even in that case, but I suppose it would be more complicated / expensive than you'd like regardless) just to resolve the name (and not so much for the actual map itself). That issue wouldn't so much be inherent to the ARB_map_buffer_range API though, but rather inherent to the specific CS design chosen.