[Bug 59147] New: rthdribl performance is worse after eeb3e5597f11063aef389598b3c8408278fa8661
http://bugs.winehq.org/show_bug.cgi?id=59147 Bug ID: 59147 Summary: rthdribl performance is worse after eeb3e5597f11063aef389598b3c8408278fa8661 Product: Wine Version: 11.0-rc2 Hardware: x86-64 URL: http://www.daionet.gr.jp/~masa/archives/rthdribl_2_0.z ip OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs@list.winehq.org Reporter: z.figura12@gmail.com CC: rbernon@codeweavers.com Regression SHA1: eeb3e5597f11063aef389598b3c8408278fa8661 Distribution: --- This was found and bisected by Henri. I actually can't reproduce it, but I'm reporting this for Henri since he's out. The crux of the matter is we're doing more GL flushes than we used to, which is not free. Tested with rthdribl, but probably affects pretty much any d3d application. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59147 --- Comment #1 from Rémi Bernon <rbernon@codeweavers.com> --- I can't reproduce this either, as in: I don't see x11drv_surface_flush or x11drv_egl_surface_flush being called regularly. Tried windowed or fullscreen mode the same. Also, opengl_drawable_flush doesn't usually involve any kind of GL flush, except in the offscreen case for child window, where there's a glFinish call, but I don't see this hitting it anyway. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59147 --- Comment #2 from Zeb Figura <z.figura12@gmail.com> --- Figured out the difference between me and Henri: he's using a HiDPI screen. I'm not sure if this is the same thing (or how HiDPI support in Wine works in general), but if I change the DPI in winecfg to something higher, I can reproduce the regression. FWIW, with current Wine I see 6 calls to opengl_drawable_flush() per frame. As you say, that doesn't result in an actual drawable flush normally. But with the DPI changed, it does. [I'll admit it also seems odd to me that opengl_drawable_flush() should be called and do nothing. If nothing else maybe it should be named differently? Also, why are we flushing on a glClear()?] -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59147 --- Comment #3 from Rémi Bernon <rbernon@codeweavers.com> --- *** Bug 59148 has been marked as a duplicate of this bug. *** -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59147 --- Comment #4 from Rémi Bernon <rbernon@codeweavers.com> --- Yes, non-default DPI usage will cause every present to go through the offscreen rendering mechanism, as we need to upscale the surfaces. This is possibly going to hurt performance already but we also need to call glFinish in that case when the surface contents are meant to become visible on screen (for cases where buffer aren't swapped for instance). Now, the whole thing isn't very well defined yes, but that's not something we can change right during code freeze. Mostly the `flush` callback is meant to commit any change done to the surface properties and contents to the host, from the presentation thread (as opposed to the `update` callback which does the same -except for the surface contents- but from the window owner thread). Regarding wgl_context_flush, it needs to be called on glClear because of the memory DC surfaces, which show that they flush the surface contents too after these calls. Still, I think the iterative changes and fixes caused the offscreen presentation to be done more often than necessary, and I think we can safely do it explicitly when it is actually going to be necessary. https://gitlab.winehq.org/wine/wine/-/merge_requests/9817 should hopefully implement this. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59147 Rémi Bernon <rbernon@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bcb1f3d29562edabfd089bedb53 | |9cf2295a5e6a8 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Rémi Bernon <rbernon@codeweavers.com> --- I believe this is fixed with bcb1f3d29562edabfd089bedb539cf2295a5e6a8 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59147 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.0-rc4. -- 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.
participants (1)
-
WineHQ Bugzilla