2011/5/2 Mathias Fröhlich <mathias.froehl...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev