> -----Original Message----- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, December 14, 2011 2:45 AM > To: zhigang.g...@linux.intel.com > Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com; > zhigang.g...@linux.intel.com > Subject: Re: [PATCH] uxa/glamor: Enable the rest glamor rendering > functions. > > On Tue, 13 Dec 2011 22:31:41 +0800, zhigang.g...@linux.intel.com > wrote: > > From: Zhigang Gong <zhigang.g...@linux.intel.com> > > > > This commit enable all the rest glamor rendering functions. > > Tested with latest glamor master branch, can pass rendercheck. > > Hmm, it exposes an issue with keeping a bo cache independent of mesa > and trying to feed it our own handles: > > Region for name 6 already exists but is not compatible > > The w/a for this would be: > > diff --git a/src/intel_glamor.c b/src/intel_glamor.c index 0cf8ed7..2757fd6 > 100644 > --- a/src/intel_glamor.c > +++ b/src/intel_glamor.c > @@ -91,6 +91,7 @@ intel_glamor_create_textured_pixmap(PixmapPtr > pixmap) > priv = intel_get_pixmap_private(pixmap); > if (glamor_egl_create_textured_pixmap(pixmap, > priv->bo->handle, > priv->stride)) { > + drm_intel_bo_disable_reuse(priv->bo); > priv->pinned = 1; > return TRUE; > } else > > but that gives up all pretense of maintaining a bo cache.
Yes, I think this impacts the performance. Actually, I noticed this problem and I spent some time to track the root cause. If everything is ok, this error should not be triggered. Although the same BO maybe reused to create a new pixmap, the previous pixmap which own this BO should be already destroyed. And the previous image created with the previous pixmap should be destroyed either. And then, when we create a new pixmap/image with this BO, MESA should not find any exist image/region for this BO. But it does happen. I tracked further into mesa internal and found that the previous image was not destroyed when we call eglDestroyImageKHR, as its reference count is decreased to zero. It's weird for me. Further tracking shows that the root cause is when I use the texture(bind to the image) as a shader's source texture, and call glDrawArrays to perform the rendering, the texture's reference count will be increased by 1 before return from glDrawArrays. And I failed to find any API to decrease it. Then this texture can't be freed when destroy that texture and thus the image's reference count will also remain 1 and can't be freed either. The attached is a simple case to show this bug. It was modified from the eglkms.c in mesa-demos. I did send this issue to mesa-dev. Don't have a solution or explanation so far. Any idea? > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
eglkms_mod.c
Description: Binary data
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
