Two patches, solving the same problem in two different ways, the 1st one ready to go, the 2nd one would need the debug statements removed.
Only apply one of those for testing, the 2nd one will be useless with the 1st one applied, but demonstrates the problem. So X-Server 1.20 RC + modesetting-ddx with DRI3/Present hangs at least KDE-5's plasmashell and makes KDE-5 unusable with that setup. As KDE's plasmashell uses QT-5's QtQuick OpenGL based rendering api's to render scene-graphs, this bug might affect other QT applications as well. This fix works, but it points to some problems in modesetting-ddx's current vblank handling, because other ddx'en seem to be mostly unaffected by this Mesa bug. The problem is that neither of these two fixes is a proper final solution, but better than nothing. It leaves the OML_sync_control extensions glXWaitForSbcOML(), glXWaitForMscOML() calls and the SGI_video_sync glXWaitVideoSyncSGI() functions broken for some use patterns. The real problem, if i understand it correctly, is the way the life-time of dri3_drawables and loader_dri3_drawables is managed atm. by Mesa's bindContext() functions. Whenever glXMakeCurrent() etc. are called to assign new/different GLXDrawables to the same context (ie. one context reused for drawing into many different drawables, as opposed to using one dedicated context for each drawable), we destroy the underlying DRIDrawables/dri3_drawables_loader_dri3_drawables and they lose all state wrt. pending bufferswaps, msc, sbc, ust. Nothing in the specs says that clients should expect to lose such state on a GLXDrawable d1 whenever they reassign drawables other than d1 to a GL context. A sequence like... 1.glXMakeCurrent(context, drawable1); 2.draw draw draw 3.glXSwapbuffers(context, drawable1); 4.glXMakeCurrent(context, drawable2); // drawable 1 loses all state! 5.glXWaitForSbcOML(dpy, drawable1, ...); ... would probably cause a hang of the client in glXWaitForSbcOML, as the function requires information stored in the "original" drawable1 up to step 3, but lost in step 4 due to dri3_drawable destruction. Patch 1 has a potentially large performance impact when switching drawables on a given context, due to the enforced wait on swap completion, but might save OML clients which do waits for sbc,msc on a separate thread, whereas patch 2 doesn't have a performance impact, but doesn't even partially solve trouble with OML_sync_control. However, i'm totally out of time atm. and probably not the right person to think about a better solution, and by dumb luck, my own application doesn't recycle the same context for different drawables, but uses a dedicated context for each drawable, so it dodges this bullet. Therefore one of these patches is either a good enough fix for the KDE hang problems atm. or a diagnosis of the problem as a starting point for brighter people to deal with the root cause ;-) Thanks, -mario _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
