http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #26 from Stefan Dösinger <stefan@codeweavers.com> --- I had a look at this. The reason why coherent maps aren't used is here:
0158:trace:d3d8:d3d8_vertexbuffer_Lock iface 089D06F0, offset 0, size 5000, data 020D1394, flags 0.
This triggers the first like of this check in wined3d/buffer.c:
if (((flags & WINED3D_MAP_WRITE) && !(flags & (WINED3D_MAP_NOOVERWRITE | WINED3D_MAP_DISCARD))) || (!(flags & WINED3D_MAP_WRITE) && (buffer->locations & WINED3D_LOCATION_SYSMEM)) || buffer->resource.pin_sysmem || !(buffer->flags & WINED3D_BUFFER_USE_BO))
And we fall back to returning a heap memory allocation to the game and then uploading it with glBufferSubData. This of course means we rely on the game's lie. This check which triggers the fallback to sysmem+upload was introduced in afb2aa2512d4c5ffa7256ce5137bc2c142a5d065 as a performance improvement. Removing it, stalling the pipeline but then letting the game write directly into the GL buffer object fixes drawing in this game but will likely cause performance issues in other games. Maybe a compromise solution would be to ignore the map range when we see that the game is doing a synchronized map of a dynamic buffer. If we stall the render pipeline doing a full upload probably won't make much of a difference - depending on the buffer size of course. Another potential issue, but it doesn't apply to this game, is that there are a few other conditions that cause us to fall back to sysmem+upload mode. One annoying one is if the game uses the buffer with a stride of 0, which means a static attribute. OpenGL has no way to load static attributes from VBOs. They have to be specified with old immediate mode vertex attribute calls, and the VBO spec explicitly states that a pointer into a VBO map must not be passed to them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.