Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.
On Wed, 14 Dec 2011 12:08:30 +0800, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
-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.
Certainly it looks like glamor is taking all necessary steps to decouple
the bo from the textures and renderbuffer upon pixmap finish. There is
one other potential race here in that the ddx will mark the bo as
purgeable as soon as it releases it back to the cache, but it may not
yet have been submitted by mesa in its execbuffer. The kernel may choose
to free the memory associated with the bo before that happens, and
may rightfully complain the userspace is doing something silly.
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.
I'm looking at update_texture_state() which appears to hold onto a
reference to the texobj until its slot is reused. If the object is
simply destroyed and the unit disabled, the slot is skipped and the old
reference remains. _mesa_update_state (which calls into
update_texture_state) would seem to be only invoked upon a draw
primitives. Binding a dummy texture/fb and doing a dummy render might be
a little extreme as a workaround!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, December 14, 2011 7:12 PM
To: Zhigang Gong
Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com
Subject: RE: [PATCH] uxa/glamor: Enable the rest glamor rendering
functions.
On Wed, 14 Dec 2011 12:08:30 +0800, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
-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.
Certainly it looks like glamor is taking all necessary steps to decouple
the
bo from the textures and renderbuffer upon pixmap finish. There is one
other potential race here in that the ddx will mark the bo as purgeable as
soon as it releases it back to the cache, but it may not yet have been
submitted by mesa in its execbuffer. The kernel may choose to free the
memory associated with the bo before that happens, and may rightfully
complain the userspace is doing something silly.
Right, we do have this race if the kernel free the BO's memory prior to
The mesa submit its execbuffer. Hmm. But I think that may not be a real
problem, as once we call intel_set_pixmap_bo(pixmap, NULL) to unlink
the bo from the pixmap, the BO will not be released at DRM layer
immediately,
instead, it will be put on a in_flight list. And intel_batch_submit will
empty the
list, considering after switching to glamor, each pixmap's batch buffer
should
be empty, then the driver will only call intel_batch_submit at
intel_flush_rendering
which is called from intel_uxa_block_handler and is after the
intel_glamor_flush.
At intel_glamor_flush, it will do a glFlush, my understanding is glFlush
should make sure the execbuffer was submitted to GPU. But I'm not very sure.
Can you confirm that? Thanks.
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.
I'm looking at update_texture_state() which appears to hold onto a
reference to the texobj until its slot is reused. If the object is simply
destroyed and the unit disabled, the slot is skipped and the old reference
remains. _mesa_update_state (which calls into
update_texture_state) would seem to be only invoked upon a draw
primitives. Binding a dummy texture/fb and doing a dummy render might
be a little extreme as a workaround!
Thanks for providing this workaround, I did try that way with my simple test
case, it works. I just wonder whether this is a bug of MESA.
I will implement it in glamor before we get a better solution.
-Chris
--
Chris Wilson, Intel
Re: [Intel-gfx] [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. Sure enough, it passes rendercheck. Well done! However, glyph rendering is off, the characters look incorrectly scaled and slightly out-of-position. And it will eventually chase a NULL pointer inside glamor's glyph cache. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.
On Wed, 14 Dec 2011 19:44:34 +0800, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, December 14, 2011 7:12 PM
To: Zhigang Gong
Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com
Subject: RE: [PATCH] uxa/glamor: Enable the rest glamor rendering
functions.
On Wed, 14 Dec 2011 12:08:30 +0800, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
-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.
Certainly it looks like glamor is taking all necessary steps to decouple
the
bo from the textures and renderbuffer upon pixmap finish. There is one
other potential race here in that the ddx will mark the bo as purgeable as
soon as it releases it back to the cache, but it may not yet have been
submitted by mesa in its execbuffer. The kernel may choose to free the
memory associated with the bo before that happens, and may rightfully
complain the userspace is doing something silly.
Right, we do have this race if the kernel free the BO's memory prior to
The mesa submit its execbuffer. Hmm. But I think that may not be a real
problem, as once we call intel_set_pixmap_bo(pixmap, NULL) to unlink
the bo from the pixmap, the BO will not be released at DRM layer
immediately,
instead, it will be put on a in_flight list. And intel_batch_submit will
empty the
list, considering after switching to glamor, each pixmap's batch buffer
should
be empty, then the driver will only call intel_batch_submit at
intel_flush_rendering
which is called from intel_uxa_block_handler and is after the
intel_glamor_flush.
At intel_glamor_flush, it will do a glFlush, my understanding is glFlush
should make sure the execbuffer was submitted to GPU. But I'm not very sure.
Can you confirm that? Thanks.
It shouldn't go on the in-flight list because we're not using
intel_batchbuffer any more and so it will not be referenced by the
batch.
This patch along with calling dispatch-glFlush() after deleting the
textured pixmap is enough to silence the warning inside mesa and
prevent the purgeable race:
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 068b305..347a5d6 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -34,6 +34,7 @@
#include main/imports.h
#include main/points.h
#include main/renderbuffer.h
+#include main/state.h
#include swrast/swrast.h
#include swrast_setup/swrast_setup.h
@@ -527,6 +528,8 @@ intel_glFlush(struct gl_context *ctx)
intel_flush_front(ctx);
if (intel-is_front_buffer_rendering)
intel-need_throttle = true;
+
+ _mesa_update_state(ctx);
}
diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
index 7cd2858..4bcaec0 100644
--- a/src/mesa/main/texstate.c
+++ b/src/mesa/main/texstate.c
@@ -557,6 +557,7 @@ update_texture_state( struct gl_context *ctx )
if (enabledTargets == 0x0) {
/* neither vertex nor fragment processing uses this unit */
+_mesa_reference_texobj(texUnit-_Current, NULL);
[Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.
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.
One thing need to be pointed out is the picture's handling.
Pictures support many different color formats, but glamor's
texture only support a few color formats. And the most common
scenario is that we create a pixmap with a color depth and
then attach it to a picture which has a specific color format
with the same color depth. But there is no way to change a
texture's internal format after the texture was allocated.
If you do that, the OpenGL will allocate a new texture. And
then the glamor side and UXA side will be inconsitence. So
for all the picture related operations, we can't fallback to
UXA path directly, even it is rather a strainth forward
operation. So for the get_image, Addtraps.., we have to add
wrappers function for them to jump into glamor firstly.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
src/intel_uxa.c | 14 +++-
uxa/uxa-accel.c | 88 -
uxa/uxa-glamor.h | 16 -
uxa/uxa-glyphs.c | 21
uxa/uxa-priv.h |8 +
uxa/uxa-render.c | 90 ++
uxa/uxa.c|4 +-
7 files changed, 234 insertions(+), 7 deletions(-)
diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index e4a5270..a79affa 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -1108,6 +1108,9 @@ intel_uxa_create_pixmap(ScreenPtr screen, int w, int h,
int depth,
list_del(priv-in_flight);
screen-ModifyPixmapHeader(pixmap, w, h, 0, 0,
stride, NULL);
intel_set_pixmap_private(pixmap, priv);
+
+ if
(!intel_glamor_create_textured_pixmap(pixmap))
+ intel_set_pixmap_bo(pixmap, NULL);
return pixmap;
}
}
@@ -1145,8 +1148,15 @@ intel_uxa_create_pixmap(ScreenPtr screen, int w, int h,
int depth,
list_init(priv-batch);
list_init(priv-flush);
intel_set_pixmap_private(pixmap, priv);
-
- intel_glamor_create_textured_pixmap(pixmap);
+ /* Create textured pixmap failed means glamor fail to create
+* a texture from the BO for some reasons, and then glamor
+* create a new texture attached to the pixmap, and all the
+* consequent rendering operations on this pixmap will never
+* fallback to UXA path, so we don't need to hold the useless
+* BO if it is the case.
+*/
+ if (!intel_glamor_create_textured_pixmap(pixmap))
+ intel_set_pixmap_bo(pixmap, NULL);
}
return pixmap;
diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c
index e4afd13..05c64f6 100644
--- a/uxa/uxa-accel.c
+++ b/uxa/uxa-accel.c
@@ -207,8 +207,23 @@ static void
uxa_put_image(DrawablePtr pDrawable, GCPtr pGC, int depth, int x, int y,
int w, int h, int leftPad, int format, char *bits)
{
+ uxa_screen_t *uxa_screen = uxa_get_screen(pDrawable-pScreen);
+
+ if (uxa_screen-info-flags UXA_USE_GLAMOR) {
+ uxa_prepare_access(pDrawable, UXA_GLAMOR_ACCESS_RW);
+ if (glamor_put_image_nf(pDrawable,
+ pGC, depth, x, y, w, h,
+ leftPad, format, bits)) {
+ uxa_finish_access(pDrawable, UXA_GLAMOR_ACCESS_RW);
+ return;
+ }
+ uxa_finish_access(pDrawable, UXA_GLAMOR_ACCESS_RO);
+ goto fallback;
+ }
+
if (!uxa_do_put_image(pDrawable, pGC, depth, x, y, w, h, format, bits,
PixmapBytePad(w, pDrawable-depth)))
+fallback:
uxa_check_put_image(pDrawable, pGC, depth, x, y, w, h, leftPad,
format, bits);
}
@@ -352,6 +367,22 @@ uxa_copy_n_to_n(DrawablePtr pSrcDrawable,
int dst_off_x, dst_off_y;
PixmapPtr pSrcPixmap, pDstPixmap;
+ if (uxa_screen-info-flags UXA_USE_GLAMOR) {
+ uxa_prepare_access(pSrcDrawable, UXA_GLAMOR_ACCESS_RO);
+ uxa_prepare_access(pDstDrawable, UXA_GLAMOR_ACCESS_RW);
+ if (glamor_copy_n_to_n_nf(pSrcDrawable, pDstDrawable,
+ pGC, pbox, nbox, dx, dy,
+ reverse, upsidedown, bitplane,
+ closure)) {
+ uxa_finish_access(pDstDrawable, UXA_GLAMOR_ACCESS_RW);
+ uxa_finish_access(pSrcDrawable, UXA_GLAMOR_ACCESS_RO);
+ return;
+ }
+
Re: [Intel-gfx] [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. One thing need to be pointed out is the picture's handling. Pictures support many different color formats, but glamor's texture only support a few color formats. And the most common scenario is that we create a pixmap with a color depth and then attach it to a picture which has a specific color format with the same color depth. But there is no way to change a texture's internal format after the texture was allocated. If you do that, the OpenGL will allocate a new texture. And then the glamor side and UXA side will be inconsitence. So for all the picture related operations, we can't fallback to UXA path directly, even it is rather a strainth forward operation. So for the get_image, Addtraps.., we have to add wrappers function for them to jump into glamor firstly. Can we create multiple textures referencing the same bo but with different formats? Or are we going to run afoul of the coherency model with GL? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [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.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.
-Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Wednesday, December 14, 2011 2:20 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. One thing need to be pointed out is the picture's handling. Pictures support many different color formats, but glamor's texture only support a few color formats. And the most common scenario is that we create a pixmap with a color depth and then attach it to a picture which has a specific color format with the same color depth. But there is no way to change a texture's internal format after the texture was allocated. If you do that, the OpenGL will allocate a new texture. And then the glamor side and UXA side will be inconsitence. So for all the picture related operations, we can't fallback to UXA path directly, even it is rather a strainth forward operation. So for the get_image, Addtraps.., we have to add wrappers function for them to jump into glamor firstly. Can we create multiple textures referencing the same bo but with different formats? AFAIK, it's impossible to match all possible picture formats to a OpenGL internal format. We have to have a new texture attached to glamor for incompatible format. The old texture is created from DDX's BO and has incorrect internal format. IMO, we can't make any use of this wrong texture within glamor, so I just don't create it and return a false to DDX layer to notify the DDX to unlink the BO. All the consequent rendering operation on this pixmap will be handled within glamor scope and target to the new texture with correct format. Or are we going to run afoul of the coherency model with GL? My understanding is, if the picture's format is incompatible with OpenGL's internal format. --Zhigang -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.
-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
