[Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.

[Zhigang Gong]

> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Wednesday, December 14, 2011 2:45 AM
> To: zhigang.gong at linux.intel.com
> Cc: intel-gfx at lists.freedesktop.org; zhigang.gong at gmail.com;
> zhigang.gong at linux.intel.com
> Subject: Re: [PATCH] uxa/glamor: Enable the rest glamor rendering
> functions.
> 
> On Tue, 13 Dec 2011 22:31:41 +0800, zhigang.gong at linux.intel.com
> wrote:
> > From: Zhigang Gong <zhigang.gong at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eglkms_mod.c
Type: application/octet-stream
Size: 10635 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111214/c0ce4753/attachment.obj>