On Sun, 10 Mar 2019 at 07:50, Alyssa Rosenzweig <aly...@rosenzweig.io> wrote:
>
> With a unified layout field, we can specify the logic for BO layout
> explicitly, deciding between linear/tiled/AFBC based on the specified
> usage/binding flags.
>
> Signed-off-by: Alyssa Rosenzweig <aly...@rosenzweig.io>
Great stuff!
Reviewed-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> ---
> src/gallium/drivers/panfrost/pan_resource.c | 64 ++++++++++++++-------
> 1 file changed, 44 insertions(+), 20 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_resource.c
> b/src/gallium/drivers/panfrost/pan_resource.c
> index 0cebbdb6e51..39783f5a63a 100644
> --- a/src/gallium/drivers/panfrost/pan_resource.c
> +++ b/src/gallium/drivers/panfrost/pan_resource.c
> @@ -181,6 +181,48 @@ panfrost_surface_destroy(struct pipe_context *pipe,
> free(surf);
> }
>
> +/* Based on the usage, figure out what storing will be used. There are
> + * various tradeoffs:
> + *
> + * Linear: the basic format, bad for memory bandwidth, bad for cache
> + * use. Zero-copy, though. Renderable.
> + *
> + * Tiled: Not compressed, but cache-optimized. Expensive to write into
> + * (due to software tiling), but cheap to sample from. Ideal for most
> + * textures.
> + *
> + * AFBC: Compressed and renderable (so always desirable for non-scanout
> + * rendertargets). Cheap to sample from. The format is black box, so we
> + * can't read/write from software.
> + */
> +
> +static enum panfrost_memory_layout
> +panfrost_best_layout(const struct pipe_resource *rsrc)
> +{
> + /* For streaming, optimize for CPU write since it's one-use */
> +
> + if (rsrc->usage == PIPE_USAGE_STREAM)
> + return PAN_LINEAR;
> +
> + /* Legal formats depends if we're renderable */
> +
> + unsigned renderable_bind =
> + PIPE_BIND_DEPTH_STENCIL |
> + PIPE_BIND_RENDER_TARGET |
> + PIPE_BIND_BLENDABLE;
> +
> + if (rsrc->bind & renderable_bind) {
> + /* TODO: AFBC */
> + return PAN_LINEAR;
> + } else if (rsrc->bind & PIPE_BIND_SAMPLER_VIEW) {
> + return PAN_TILED;
> + }
> +
> + /* If all else fails, we default to linear */
> +
> + return PAN_LINEAR;
> +}
> +
> static struct panfrost_bo *
> panfrost_create_bo(struct panfrost_screen *screen, const struct
> pipe_resource *template)
> {
> @@ -195,26 +237,8 @@ panfrost_create_bo(struct panfrost_screen *screen, const
> struct pipe_resource *t
> if (template->height0) sz *= template->height0;
> if (template->depth0) sz *= template->depth0;
>
> - /* Based on the usage, figure out what storing will be used. There
> are
> - * various tradeoffs:
> - *
> - * Linear: the basic format, bad for memory bandwidth, bad for cache
> - * use. Zero-copy, though. Renderable.
> - *
> - * Tiled: Not compressed, but cache-optimized. Expensive to write
> into
> - * (due to software tiling), but cheap to sample from. Ideal for most
> - * textures.
> - *
> - * AFBC: Compressed and renderable (so always desirable for
> non-scanout
> - * rendertargets). Cheap to sample from. The format is black box, so
> we
> - * can't read/write from software.
> - */
> -
> - /* Tiling textures is almost always faster, unless we only use it
> once */
> - bool should_tile = (template->usage != PIPE_USAGE_STREAM) &&
> (template->bind & PIPE_BIND_SAMPLER_VIEW);
> -
> - /* Set the layout appropriately */
> - bo->layout = should_tile ? PAN_TILED : PAN_LINEAR;
> + bo->imported_size = sz;
> + bo->layout = panfrost_best_layout(template);
>
> if (bo->layout == PAN_TILED) {
> /* For tiled, we don't map directly, so just malloc any old
> buffer */
> --
> 2.20.1
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
