3 ms·

glMapBuffer doesn't have any ability to declare that you won't overwrite data. All you can say is whether you want read/write access to the buffer. So the drive

glMapBuffer doesn't have any ability to declare that you won't overwrite data. All you can say is whether you want read/write access to the buffer. So the driver has to assume that the client might overwrite in-flight data, so synchronization is required. As for the command stream handling, it makes decent sense to do translation up-front and your drawing commands into a command stream so a separate thread can just hammer through it as fast as possible, rather than doing GL calls in-line with the translation. Partly so the game can return to doing its thing as fast as possible, and partly to fix issues with GL's threading model being horrible ( see e.g. https://bugs.winehq.org/show_bug.cgi?id=24684 https://bugs.winehq.org/show_bug.cgi?id=24684 )

kllrnohj 9y ago
> glMapBuffer doesn't have any ability to declare that you won't overwrite data. Well, yes and no. glMapBufferRange, which is basically a drop-in replacement for glMapBuffer, does have such a flag, it's GL_MAP_UNSYNCHRONIZED_BIT. glMapBufferRange requires OpenGL 3.0 whereas glMapBuffer exists all the way back to OpenGL 2.0 but this looks more like just an oversight in Wine than anything else.
- twtw 9y ago
  Wine uses glMapBufferRange when available, and has logic to translate D3DLOCK_NOOVERWRITE to GL_MAP_UNSYNCHRONIZED_BIT. I don't understand what the current implementation is doing that is causing wined3d_resource_map to block. https://github.com/wine-mirror/wine/blob/538263d0efe725124df88ce1cce124bc3ad7e2af/dlls/wined3d/resource.c#L422 https://github.com/wine-mirror/wine/blob/538263d0efe725124df...