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. 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? > 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. > 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. -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev