<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> On 05/02/11 22:20, Mathias Fröhlich wrote: <blockquote cite="mid:201105022220.53992.Mathias.Froehlich@gmx.net" type="cite"> <pre wrap=""> Hi, On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <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. </pre> </blockquote> <pre wrap=""> 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> </blockquote> <pre wrap="">Ok, so there is sufficient space ... </pre> <blockquote type="cite"> <blockquote type="cite"> <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 prolem? </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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. !?! </pre> </blockquote> 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 <blockquote cite="mid:201105022220.53992.Mathias.Froehlich@gmx.net" type="cite"> <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? Greetings Mathias </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ mesa-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</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> </pre> </blockquote> </body> </html>