[Mesa-dev] [PATCH 1/3] gallium: add resource normalization flags (v4)

Roland Scheidegger sroland at vmware.com
Wed Aug 18 06:46:26 PDT 2010


On 17.08.2010 21:54, Luca Barbieri wrote:
> Changes in v4:
> - Use a single flag for state tracker -> driver like in v1, but with
>   a better name and separated from the other flags
> - Fully clarify semantics of that flag
> 
> Changes in v3:
> - Rework to use multiple flags
> 
> Changes in v2:
> - Add a much longer and better comment
> 
> This allows:
> 1. The state tracker to tell the driver which normalizations it needs
> 2. The driver to tell the state tracker which normalization it prefers
> ---
>  src/gallium/include/pipe/p_defines.h |   55 ++++++++++++++++++++++++++++++++++
>  1 files changed, 55 insertions(+), 0 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
> index 00aa207..9625d52 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -313,6 +313,61 @@ enum pipe_transfer_usage {
>  /* Flags for the driver about resource behaviour:
>   */
>  #define PIPE_RESOURCE_FLAG_GEN_MIPS    (1 << 0)  /* Driver performs autogen mips */
> +
> +/*
> + * PIPE_CAP_FLEXIBLE_SAMPLING is a fictitious cap that doesn't currently
> + * exist, but will be supported by OpenCL-capable cards.
> + *
> + * If PIPE_CAP_FLEXIBLE_SAMPLING is supported:
> + * - PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is ignored
> + * - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver,
> + *      should use unnormalized coordinates, but can use normalized too
> + * - If PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS is set by the driver,
> + *      should use normalized coordinates, but can use unnormalized too
> + * - Otherwise, can use any normalization indifferently
> +
> + * If PIPE_CAP_FLEXIBLE_SAMPLING is not set
> + *    and PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is set:
> + * - last_level must be 0
> + * - Must use a clamp wrap mode
> + * - if PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS is set by the driver,.
> + *      should use normalized coordinates, but can use unnormalized too
> + * - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver
> + *      must use unnormalized coordinates
> + * - Otherwise, can use any normalization indifferently
> +
> + * If PIPE_CAP_FLEXIBLE_SAMPLING is not set
> + *    and PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is not set:
> + * - If NPOT and PIPE_CAP_NPOT_TEXTURES is not supported,
> + *      last_level must be 0
> + * - If using unnormalized coordinates or
> + *    if NPOT and PIPE_CAP_NPOT_TEXTURES is not supported
> + *       Must use a clamp wrap mode
> + * - if PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS is set by the driver,.
> + *      must use normalized coordinates
> + * - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver
> + *    and NPOT and PIPE_CAP_NPOT_TEXTURES is not supported,
> + *      must use unnormalized coordinates
> +  - if PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS is set by the driver
> + *    and POT or PIPE_CAP_NPOT_TEXTURES is supported,
> + *      should use unnormalized coordinates, but can use normalized too
> + * - Otherwise, can use any normalization indifferently
> + */
> +#define PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS (1 << 1)
> +
> +/* State trackers must not set these flags.
> + *
> + * Drivers should set these flags to inform the state tracker of the normalization
> + * it should use in internal drawing code, if they prefer any.
> + *
> + * Drivers who need to always have the same normalization used for a given
> + * resource must set either flag depending on whether
> + * PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS has been specified by the
> + * driver
> + */
> +#define PIPE_RESOURCE_FLAG_PREFER_UNNORMALIZED_COORDS (1 << 2)
> +#define PIPE_RESOURCE_FLAG_PREFER_NORMALIZED_COORDS (1 << 3)
> +

Hmm this is indeed rather complicated, though I guess it could work.
Personally I still like this better than the different bind flags, but
other people's opinion may differ...

Roland


More information about the mesa-dev mailing list