Hi Chris, On Sat, Feb 21, 2015 at 11:55 AM, Chris Wilson <[email protected]> wrote: > 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.
Thanks for looking into this! I'm attaching an updated version of the workaround; I found a problem with the first one, but I can't recall exactly what happened. Also, the latest version of Mali (almost) fixes this issue. Anyway, fixing this properly does sound like a good idea. You mentioned GLX though - would that also solve the issue in the case where EGL is used instead of GLX? Thanks Daniel
https://github.com/endlessm/eos-hw-enablement/issues/3 From 2ccbff37be778e2c13dc26fa6cd0f6ecd6f227c3 Mon Sep 17 00:00:00 2001 From: Daniel Drake <[email protected]> Date: Fri, 7 Feb 2014 08:29:38 -0600 Subject: [PATCH] dri2: work around broken DRI2CreateDrawable callers 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. Signed-off-by: Daniel Drake <[email protected]> --- hw/xfree86/dri2/dri2.c | 7 +++++++ 1 file changed, 7 insertions(+) Index: xorg-server-1.13.3/hw/xfree86/dri2/dri2.c =================================================================== --- xorg-server-1.13.3.orig/hw/xfree86/dri2/dri2.c 2014-02-25 10:37:59.002464709 -0600 +++ xorg-server-1.13.3/hw/xfree86/dri2/dri2.c 2014-02-25 11:38:29.229158820 -0600 @@ -101,6 +101,7 @@ int swap_limit; /* for N-buffering */ unsigned long serialNumber; Bool needInvalidate; + Bool client_created; int prime_id; PixmapPtr prime_slave_pixmap; PixmapPtr redirectpixmap; @@ -215,6 +216,7 @@ if (pPriv == NULL) return NULL; + pPriv->client_created = FALSE; pPriv->dri2_screen = ds; pPriv->drawable = pDraw; pPriv->width = pDraw->width; @@ -343,6 +345,15 @@ int rc; pPriv = DRI2GetDrawable(pDraw); + if (pPriv && dri2_id_out == NULL && pPriv->client_created) { + /* We already allocated a DRI2Drawable for this drawable, the client + * has called into this function (so will receive invalidate events) + * and now we're being called by the client again (we know this because + * the caller doesn't care about the dri2_id). This means we don't need + * to allocate another one, we have nothing else to do. */ + pPriv->prime_id = dri2_client->prime_id; + return Success; + } if (pPriv == NULL) pPriv = DRI2AllocateDrawable(pDraw); if (pPriv == NULL) @@ -357,6 +368,11 @@ if (dri2_id_out) *dri2_id_out = dri2_id; + else { + /* The client has called in for the first time, it will now receive + * invalidate events. Record this for later. */ + pPriv->client_created = TRUE; + } return Success; }
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
