Am Donnerstag, den 24.01.2019, 07:46 +0100 schrieb Christian Gmeiner:
> Am Mo., 21. Jan. 2019 um 10:10 Uhr schrieb Lucas Stach
> <l.st...@pengutronix.de>:
> >
> > Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> > > If the GPU supports linear sampling, linear addressing mode
> > > will be used as default.
> > >
> > > > Signed-off-by: Christian Gmeiner <christian.gmei...@gmail.com>
> > >
> > > ---
> > > src/gallium/drivers/etnaviv/etnaviv_resource.c | 10 +++++++---
> > > src/gallium/drivers/etnaviv/etnaviv_texture.c | 4 +++-
> > > 2 files changed, 10 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > index 9a7ebf3064e..7d24b1f03bd 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > @@ -318,9 +318,9 @@ etna_resource_create(struct pipe_screen *pscreen,
> > > {
> > > struct etna_screen *screen = etna_screen(pscreen);
> > >
> > > - /* Figure out what tiling and address mode to use -- for now, assume
> > > that
> > > - * texture cannot be linear. there is a capability
> > > LINEAR_TEXTURE_SUPPORT
> > > - * (supported on gc880 and gc2000 at least), but not sure how it
> > > works.
> > > + /* Figure out what tiling and address mode to use.
> > > + * Textures are TILED or LINEAR. If LINEAR_TEXTURE_SUPPORT capability
> > > is
> > > + * available LINEAR gets prefered.
> > > * Buffers always have LINEAR layout.
> > > */
> > > unsigned layout = ETNA_LAYOUT_LINEAR;
> > > @@ -334,6 +334,10 @@ etna_resource_create(struct pipe_screen *pscreen,
> > >
> > > if (util_format_is_compressed(templat->format))
> > > layout = ETNA_LAYOUT_LINEAR;
> > > + else if (VIV_FEATURE(screen, chipMinorFeatures1,
> > > LINEAR_TEXTURE_SUPPORT)) {
> > > + layout = ETNA_LAYOUT_LINEAR;
> > > + mode = ETNA_ADDRESSING_MODE_LINEAR;
> > > + }
> >
> > Did you do any performance measurements with this change? I don't think
> > we generally want to prefer linear textures, as in theory they have
> > much worse texture cache hit rates. Also a lot of the async transfer
> > stuff currently depends on hitting the RS linear->tiled blit path for
> > optimal performance on uploads.
> >
>
> I have not done any performance measurements yet - I only tried to get it
> render correctly (piglit and amoeba) and get some feedback asap.
> But I will keep an eye on perf for v2.
FWIW, I did some preliminary testing and couldn't find a big perf
difference. Even after a hack to use linear textures more often (in
most cases we end up with textures being allocated with both SAMPLER
and RENDER binding, where we still end up with tiled resources.
But my tests didn't pound very hard on sampler performance.
> Regarding the async transfer staff I have the feeling that we lose the shadow
> resource (etna_transfer->rsc) handling if we are using linear, which saves us
> from some RS blits. Or?
That's right, but at the price that the CPU side of the transfer needs
to synchronize with the GPU job. Getting rid of those synchronization
points was one of the key performance optimizations up until now.
Basically we are trading the overhead of a temporary buffer allocation
and a RS blit (which is only done to the part of the buffer that is
actually updated) against a full GPU stall in most cases. I'm not
saying that getting rid of the RS blit for some of the transfers won't
be beneficial, but we need to carefully weight the performance
implications here. Being able to directly map the texture resource and
blindly doing this when possible (what our current transfer code does)
will not be a net win in performance in most cases.
> > There are 2 cases where I think linear textures are useful:
> >
> > 1. Imported external buffers, where we might need to update the
> > internal tiled copy on each resource update. Getting rid of this blit
> > should help performance a good bit.
> >
>
> You are taking about etna_resource_from_handle(..). I *think* for this we
> need support for linear in the pixel engine too - based on the binding flag
> combinations I have seen.
That would be ideal, but for a start we can just keep the external
imported resource as linear and keep a tiled base resource, just as we
do now. Linear texture sampling support would already allow us to
sample the external import directly, without the need to do a copy into
a tiled texture resource.
> > 2. 8bpp formats that can't be tiled with the RS and would hit the
> > software fallback path. The tradeoff software tiling path vs. reduced
> > texture cache hit rates might still prefer linear textures.
> >
>
> Yes that I something to look into.
>
Regards,
Lucas
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
