https://bugs.winehq.org/show_bug.cgi?id=47380
--- Comment #13 from Tim Schumacher timschumi@gmx.de --- (In reply to Henri Verbeet from comment #12)
Mostly just what the "correct" thread is.
In case wined3d_cs_mt_finish() gets called from wined3d_cs_run(), wined3d_cs_mt_finish() can't just wait for the queue to become empty, because it wouldn't be making any progress. Fortunately, the fact that it gets called at all means all previous commands have already finished, so we can just return.
Got it. I also only just now noticed that the singlethreaded finish method is empty, which probably would have cleared up my confusion way earlier.
It currently wait by just spinning. That's straightforward, but not always optimal. It may be better to sleep depending on e.g. the distance between the head and the tail. The larger problem is still likely that we're calling wined3d_cs_map() at all.
Is it "the programs fault" (which it probably shouldn't be, because wine tries to implement things with the same behaviour as on Windows) for doing unusual stuff, or is wine's general implementation of this flawed, so that it maps more often than needed (which is, as far as I understood, quite an expensive operation)? I apparently can't see the full stack trace in the debugger (since it starts with d3d9_vertexbuffer_Lock or d3d9_vertexbuffer_Unlock), I'll try and capture the shortest +d3d,+d3d9 log possible and attach that instead.