[Mesa-dev] [RFC 0/1] Port dri2GetBuffersWithFormat/dri2GetBuffers to XCB

[gregory hainaut]

On Thu, 27 Apr 2017 17:11:30 +0900
Michel Dänzer <michel at daenzer.net> wrote:

> On 26/04/17 07:06 PM, Gregory Hainaut wrote:
> > On 4/26/17, Michel Dänzer <michel at daenzer.net> wrote:  
>  [...]  
>  [...]  
>  [...]  
> > 
> > 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).
> >   
>  [...]  
>  [...]  
>  [...]  
> > 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.

Hello Michel,

Yeah me too. Besides libX11 relies on (the thread-safe) XCB too.
 
> > 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.
So I tried drd. Unfortunately I'm afraid that my testcase (PCSX2) is way 
too complex for this kind of tool.

However, I always got a huge value on the reply->count in GetBuffer. I
investigated it further. Reply->count was 94373760 which can be read
as 1440,1920 so my surface resolution. I think it is enough to prove that
xcb_dri2_get_buffers_with_format_reply is stealing the reply of XGetGeometry.

Note my 2nd kind of crash is XIOError due to a null reply on XGetGeometry.
which make sense based on the above behavior.

FWIW, the crash seem to be gone with this patch + my PCSX2-XCB patches.

However, I need to check DRI3 behavior when I resize the window. As you said
it could trigger buffer invalidation too.
 
> 
>  [...]  
>  [...]  
> > 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.
> 
It is good idea. I will check, if I can manage to implement such a check.

Cheers,
Gregory