On Sun, Feb 22, 2015 at 02:09:36AM +0200, Ville Syrjälä wrote:
On Sat, Feb 21, 2015 at 10:52:49PM +, Chris Wilson wrote:
On Sun, Feb 22, 2015 at 12:13:38AM +0200, Ville Syrjälä wrote:
On Sat, Feb 21, 2015 at 09:31:07PM +, Chris Wilson wrote:
With the current protocol and
On Sun, Feb 22, 2015 at 09:02:41AM +, Chris Wilson wrote:
Yes, that is what I think the mesa patch is about. I think the solution
would have been that the DRI2Drawable take a refcnt on its parent and
then DRI2DestroyDrawable could be made to work. However, if we did that
today we would end
On Sat, Feb 21, 2015 at 10:52:49PM +, Chris Wilson wrote:
On Sun, Feb 22, 2015 at 12:13:38AM +0200, Ville Syrjälä wrote:
On Sat, Feb 21, 2015 at 09:31:07PM +, Chris Wilson wrote:
With the current protocol and implementations, we have to often call
DRI2CreateDrawable but can never
On Sat, Feb 21, 2015 at 09:31:07PM +, 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
On Sun, Feb 22, 2015 at 12:13:38AM +0200, Ville Syrjälä wrote:
On Sat, Feb 21, 2015 at 09:31:07PM +, 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
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
