From patch 5/5:
Originally written to avoid triggering a Mesa slowpath introduced by Mesa commit e7f3a8d6959c74f63c877dd8776fe519d54f946f. It seems to me like this would be a good idea for more reasons than just that though.
It may be worth mentioning those reasons then.
I guess. Avoiding multiple contexts in the most common case (which is, CSMT enabled) avoids a lot of unnecessary complication, like the context reacquire thing for event queries. Also it should fix bug 43773 (see https://bugs.winehq.org/show_bug.cgi?id=43773#c3 in particular). I suspect there are more bugs due to the same root cause (I seem to have a vague recollection of at least another application incurring the same issue but as usual I didn't keep notes, or I can't find them anyway :/)
For reference, from last time:
2020-12-03 18:52:45 @henri Mystral: 197149 caught my eye; do we actually hit that? 2020-12-03 18:56:47 @henri looking at https://cgit.freedesktop.org/mesa/mesa/commit/?id=e7f3a8d6959c74f63c877dd8776fe519d54f946f my guess would be the issue would mostly go away if we did event queries the Vulkan way 2020-12-03 18:57:03 @henri (i.e., wined3d_query_event_vk_issue()/wined3d_query_event_vk_poll()) 2020-12-03 20:31:10 @Mystral I don't know if it matters with the new event queries stuff but it did destroy perf with my branch 2020-12-03 20:32:38 @Mystral IIUC it flushes all the pending commands every time you FenceSync 2020-12-03 20:34:03 @Mystral if there are more than 1 contexts around, which is usually the case with current Wine and d3d11Yeah, we do hit it and it was bad last time I checked (which was with upstream Wine as of a few months ago IIRC). I don't think I followed up with the event queries rework, as I understand it it wouldn't solve the issue and there seem to be more reason than just that to remove the per-swapchain constraint to our GL contexts.
In general, yes, I agree; after we got wined3d_context_gl_update_window() and GL3 windowless context, there no longer seems to be a huge need to tie GL contexts to a swapchain, and it's probably more of a hindrance than a benefit at this point.
I do wonder whether you did much testing (or had it done by someone else) with applications using multiple swapchains for this patch. In particular, MS Office and various WPF applications come to mind.
Finally, there's the question of whether less than a month before the code freeze is the right time to make this kind of fundamental change. I suppose we've already done worse this cycle, so perhaps it's fine.
I can put some of this discussion into the relevant commit messages, if that's useful.
I generally think it is, yes.