On Wed, Nov 01, 2017 at 11:52:55AM +0100, Lucas Stach wrote: > Am Mittwoch, den 01.11.2017, 11:17 +0100 schrieb Wladimir J. van der Laan: > > GC3000 resolve-in-place assumes that the TS state is configured. > > If it is not, this will result in MMU errors. This is especially > > apparent when using glGenMipmaps(). > > > > Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c. > > > > > Signed-off-by: Wladimir J. van der Laan <laa...@gmail.com> > > --- > > src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 ++++ > > src/gallium/drivers/etnaviv/etnaviv_emit.c | 4 ++++ > > src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 + > > src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++ > > 4 files changed, 11 insertions(+) > > > > Ooops. This seems like an obvious oversight but I hadn't thought we would > > get > > into this path at all when there is no TS to "flush". > > And that's probably what we should fix. The self-resolve cases on > resource flush and sampler update don't check the TS status, but they > are only useful if there is a valid TS. > > With the change you did here we are still wasting bandwidth for a no-op > blit on older cores like GC880 when generating mipmaps.
Yes, just a bugfix (my original commit did not introduce the higher-level behavior). This particular case should not result in a MMU error. If we fix the higher level, then this could be replaced with an assertion instead. On the longer run I'd personally prefer to make "Flush resource level TS" a separate, explicit operation, for example a method on the context, and not make it go through the blit path with source==destination. It's a hardware operation implemented differently on GC3000 and GC7000, that just happens to use the RS blit on <GC3000. Wladimir _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
