[Mesa-dev] r600g on rv635 and broken mipmaps

[Gustaw Smolarczyk]

I can confirm this breakage on rv670 too. It may be related to all
chips < RV710 (just a guess).
The bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=35312

I compile mesa with attached patch since then, but that flush should
indeed be implicit, not explicit.

2011/4/30 Mathias Fröhlich <Mathias.Froehlich at gmx.net>:
>
> Hi,
>
> Since the lazy gpu flush changes for r600g about two weeks ago, I get broken
> mipmaps on my notebooks rv635.
> I am not sure if my analysis is right, but it appears to me that flushing the
> destination caches like it is done in r600_context_flush_dest_caches is not
> sufficient for my rv635. Since then, I need the attached patch to get correct
> automatically generated mipmaps.
> The important callpath for my observed breakage is when
> r600_context_flush_dest_caches is called from r600_set_framebuffer_state, which
> is called on each new mipmap level. With the attached change it is sufficient
> for flushing the previously rendered level that is used as a sampler source for
> rendering the next level. Without that flush, I get garbage in the smaller
> mipmap levels.
>
> 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.
> Also I cannot hear so much people screaming, so I guess the rv635 is about the
> only chip that suffers from this problem.
> But I failed to find that finegrained bo flush with the apropriate flush flags that
> makes mipmaps work again.
>
> 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?
>
> Greetings
>
> Mathias
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>