On 26/04/17 07:06 PM, Gregory Hainaut wrote: > On 4/26/17, Michel Dänzer <mic...@daenzer.net> wrote: >> On 26/04/17 05:07 PM, Gregory Hainaut wrote: >>> Following the discussion in "[PATCH v4 0/3] asynchronous pbo transfer with >>> glthread" >>> >>> It will help apps that are ported to XCB. >> >> How so? > > I didn't test it (yet). But I think it is safe to call XCB from > various threads. However if one thread use XLIB, you're screwed (to > access the same display). > >> >>> But Xlib (without XInitThread) apps will still crash when glthread is >>> enabled on DRI2. >> >> Do the crashes provide information about where glthread is still calling >> libX11 APIs? > I far from an expert so maybe I misunderstand some stuffs. So, as far > as I understand XLIB and XCB are mixed together. They likely share the > same queues. > > Let's say you have an app that does Xlib operations on display (for > example XGetGeometry). As XInitThread wasn't called, you're in YOLO > mode. > > glthread (gallium->DRI2) will do operation (GetBuffer) on the same > display through an XCB connection but it is still the same display. > XCB might lock it properly but Xlib call is lock-free.
I was hoping the lower XCB layer could be used in a thread-safe way even if the higher libX11 layer isn't. But maybe that's just wishful thinking. > What happen in my case is that XCB reply was corrupted (count was huge > which lead to memory bad access). My guess was that Xlib calls from > app were the culprit. It would be nice to get some certainty, e.g. via the valgrind helgrind/drd tools. >>> There are 3 remaining possibilities >>> * Won't fix. DRI3/XCB is the future >>> * Enable thread safe Xlib by default (which would make sense in multicore >>> CPU era) >>> * Track gl call that will use X11 API to force a sync >> >> Until either of the latter two happens, glthread should only be enabled >> with DRI3. > On one hand, I don't like crash neither but in other hand, it would be > nice to keep glthread for application that call XInitThread properly. We could check dpy->lock_fns and only enable glthread with DRI2 if it's non-NULL. If it's NULL and the environment variable mesa_glthread=true is set, we could print a warning to stderr explaining that glthread can't be enabled because the application didn't call XInitThreads. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
