[Mesa-dev] r600g on rv635 and broken mipmaps

Alex Deucher alexdeucher at gmail.com
Mon May 2 13:59:39 PDT 2011


2011/5/2 Mathias Fröhlich <Mathias.Froehlich at gmx.net>:
>
> 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.
>

One thing to double check is that rv6xx_context_surface_base_update()
gets emitted properly every time a base address is emitted.  Right now
I think we only call it once per command buffer, but it needs to be
emitted every time a base address changes.

Alex

> 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
>
>


More information about the mesa-dev mailing list