[Mesa-dev] [PATCH] [RFC] r600g: improve flushed depth texture allocation

[Vadim Girlin]

On Sun, 2012-06-24 at 17:43 +0200, Marek Olšák wrote:
> Hi Vadim,
> 
> This is:
> 
> Reviewed-by: Marek Olšák <maraeo at gmail.com>
> 
> I'd like to point out an issue here, which has nothing to do with your
> patch, just so you know.
> 
> Flushing in create_sampler_view is wrong. Some people have been
> wondering why depth flushes are not realiable while there is such
> an obvious mistake right in front of them. create_sampler_view has
> nothing to do with rendering. The only thing we know for sure is that
> create_sampler_view is called sometime before the sampler view is used
> (obviously), but it can be called anytime, even at context creation.
> The correct place where the depth buffer should be flushed is
> set_*_sampler_views (or anytime before the next drawing operation).
> 

Hi, Marek,

If I'm not missing something, depth flushing is already implemented as
you said - we're just creating the texture for flushed depth in the
create_sampler_view, and real flush is performed in the
r600_update_derived_state. Though I suspect there is a problem with this
patch if flushed depth texture is reallocated after creating sampler
view state, because sampler view is not updated then. Thanks for
pointing that out.

Probably we might want to keep flushed depth texture always in VRAM and
use separate staging texture for transfers, instead of reallocation.
I'll try to implement it that way.

Vadim


> Marek
> 
> On Sun, Jun 24, 2012 at 3:43 PM, Vadim Girlin <vadimgirlin at gmail.com> wrote:
> > Allocate flushed depth texture in the VRAM if we aren't going to access it by
> > CPU. If we need CPU access later, then it'll be reallocated in the GTT.
> > Currently it's not reallocated in the opposite direction (GTT->VRAM), though
> > probably we might want to do it too. Anyway, it helps the apps that don't need
> > to access flushed depth texture by CPU at all, e.g. Lightsmark.
> >
> > Improves performance for Lightsmark.
> >
> > Signed-off-by: Vadim Girlin <vadimgirlin at gmail.com>
> > ---
> >
> > No regressions on evergreen, also it somehow fixes fbo-clear-formats and
> > fbo-generate-mipmap-formats, that were failing on depth/stencil formats.
> >
> >  src/gallium/drivers/r600/evergreen_state.c |    5 +++--
> >  src/gallium/drivers/r600/r600_blit.c       |    2 +-
> >  src/gallium/drivers/r600/r600_resource.h   |    3 ++-
> >  src/gallium/drivers/r600/r600_state.c      |    2 +-
> >  src/gallium/drivers/r600/r600_texture.c    |   31 ++++++++++++++++++++--------
> >  5 files changed, 29 insertions(+), 14 deletions(-)