Limit DRI2Drawable reference leak

[Chris Wilson]

On Sun, Feb 22, 2015 at 12:13:38AM +0200, Ville Syrjälä wrote:
> On Sat, Feb 21, 2015 at 09:31:07PM +0000, Chris Wilson wrote:
> > With the current protocol and implementations, we have to often call
> > DRI2CreateDrawable but can never call DRI2DestroyDrawable. This ends up
> > with us leaking references to DRI2Drawables based on the assumption that
> > the references have identical lifetimes to the Drawable going astray.
> > This was spotted by Daniel Drake as the mali driver would create a new
> > reference to the DRI2Drawable on every GetBuffers, but it can also be
> > observed in mesa when running synthetic benchmarks (creating lots of
> > contexts/glxdrawables for each window) and to a lesser extent with
> > normal composited operation.
> > 
> > The first two patches implement the capping of the unnamed internal
> > reference used by DRI2CreateDrawable to just one per Client.
> 
> IIRC we had many issues around the dri2 reference stuff during the
> Maemo days. Pauli fixed tons of problems in the dri2 code but some
> of the patches never made it in.
> 
> These seem somewhat relevant:
> http://lists.x.org/archives/xorg-devel/2010-November/014783.html
> http://lists.x.org/archives/xorg-devel/2010-November/014782.html

Indeed. Same problem, similar solution. I was a bit dubious as to
whether we could hook up DRI2DestroyDrawable after all this time (for
example mesa ignores it except for GLXPixmaps) and feared there was some
corner case that was going to explode. Separating the two resource types
cleans up the code slightly and should speed it as well (if many
references do persist).

Further info, the leak is a result of the conversion in:
xserver commit 1da1f33f2dd5b437dd56cd9f5d6782de4ad5a1bc
Author: Kristian Høgsberg <krh at bitplanet.net>
Date:   Fri Apr 16 05:55:34 2010 -0400

    DRI2: Track DRI2 drawables as resources, not privates
    
    The main motivation here is to have the resource system clean up the
    DRI2 drawable automatically so glx doesn't have to.  Right now, the
    glx drawable resource must be destroyed before the X drawable, so that
    calling DRI2DestroyDrawable doesn't crash.  By making the DRI2
    drawable a resource, GLX doesn't have to worry about that and the
    resource destruction order becomes irrelevant.

But the scary one is
mesa commit 4ebf07a426771b62123e5fcb5a8be0de24037af1
Author: Kristian Høgsberg <krh at bitplanet.net>
Date:   Mon Sep 13 08:39:42 2010 -0400

    glx: Don't destroy DRI2 drawables for legacy glx drawables
    
    For GLX 1.3 drawables, we can destroy the DRI2 drawable when the GLX
    drawable is destroyed.  However, for legacy drawables, there os no
    good way of knowing when the application is done with it, so we just
    let the DRI2 drawable linger on the server.  The server will destroy
    the DRI2 drawable when it destroys the X drawable or the client exits
    anyway.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=30109

Which leads me to believe that pushing the named references out to the
Clients requires less thinking...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre