On Fri, Feb 07, 2014 at 08:43:11AM -0600, Daniel Drake wrote: > The state of the DRI2CreateDrawable request is a little unclear. > dri2proto.txt states that it was dropped in version 1.99.2, but > actually this must still be called exactly once for each drawable > before GetBuffers and friends can be called, because it is the only > way that the internal DRI2DrawableRec structure will be allocated. > > Mali fails to obey this unwritten rule and instead calls CreateDrawable > before each and every GetBuffers request. That causes a new dri2_id and > internal reference to be created every time. When we then come to > invalidate the drawable after GetBuffers+SwapBuffers for frame N, we end > up generating N invalidate events from DRI2InvalidateDrawable. Things > quickly get out of hand. > > Fix this by detecting the fact that we're being called from > the DRI2CreateDrawable request context (i.e. caller does not get to > learn about the assigned dri2_id). In that case, just ensure that > we have allocated the relevant internal DRI2 private data, and return.
I recently came across something very similar because it affects mesa also. The problem is that we do want to track a reference per Client, so simply creating a single reference seems fraught with danger. For mesa, I thought using a named reference, i.e. passing the dri2_id from the Client to use for the reference, and then destroying that reference along with mesa's glXDrawable, actually fixes a few bugs in mesa/src/glx/dri2_glx.c Did you find an alternative solution for mali? If not, I think I can generalise this into only allocating a single reference per DRI2 Client per Drawable. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
