[Mesa-dev] r600g on rv635 and broken mipmaps

[Mathias Fröhlich]

Hi,

On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
> > 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.
Ok, so there is sufficient space ...

> > May be this does ring some bell which flush is missing?
> > If not, does somebody have any clue which chips do suffer from this
> > prolem?
> 
> 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:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=36525
> 
> 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. !?!

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?

Greetings

Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-r600g-Emit-a-cache-flush-invalidate-on-a-dest-cache-.patch
Type: text/x-patch
Size: 2115 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110502/997a8451/attachment.bin>