<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html; charset=ISO-8859-1"
<body text="#000000" bgcolor="#ffffff">
On 05/02/11 22:20, Mathias Fröhlich wrote:
On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
<pre wrap="">So, I know that this patch is not applicable, since it does not account
for sufficient cs space for this additional flush. Also it is probably
too croase in face of the finegrained bo flush logic.
Actually I think it should be fine, since this event type is about the
destination and smx caches if I'm reading the documentation right.
There's also a small margin in the dwords reserved for context_flush;
it only uses 10 of the 16 dwords reserved for it.
<pre wrap="">Ok, so there is sufficient space ...
<pre wrap="">May be this does ring some bell which flush is missing?
If not, does somebody have any clue which chips do suffer from this
I think it's rv6xx that's a bit special. There is a also a bug report about
random GPU lockups with those chipsets since the cache flush changes:
<a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/show_bug.cgi?id=36525">https://bugs.freedesktop.org/show_bug.cgi?id=36525</a>
I thought adding this event write might fix that, but apparently it didn't.
My patch wrote the packet before flushing the buffers though.
I have again spent some more tries with different kinds of flushes on the rv635.
What helps for the mipmap problem here is emitting a texture_barrier as well
as flushing anything that covers the whole memory range and more than two
arbitrary color buffers. !?!
Maybe this problem happens because the texture cache does not get
invalidated. The texture cache only gets invalidated when we are
emitting dirty blocks, but the mipmap function doesn't change the
sampler_views so the resource block will not be marked dirty.
Therefore, we render with partly the old contents of the texture.
texture_barrier flushes the texture cache besides the colorbuffer
caches, so if that works the problem could be that the texture cache
is not invalidated.<br>
<pre wrap="">Given your comment I have implemented a two alternative flush paths one for the
rv6xx chips which does just the brutal cache flush invalidate and one for the
rest which still uses the selective bo flushes.
For my rv635 this works.
Does this also fix 35312?
mesa-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firstname.lastname@example.org">email@example.com</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>