[Mesa-dev] r600g on rv635 and broken mipmaps

[Bas Nieuwenhuizen]

On 05/02/11 22:20, Mathias Fröhlich wrote:
> 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. !?!
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.

Best regards,

Bas Nieuwenhuizen
> 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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110503/210e959d/attachment.htm>