[Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

Roland Scheidegger sroland at vmware.com
Sat Feb 22 04:02:44 PST 2014


Am 22.02.2014 04:04, schrieb Emil Velikov:
> According to the GLX_MESA_query_renderer spec each driver should
> be able to report the version of each GL api they support before
> creating a context.
> 
> Currently both classic mesa and gallium evaluate the version post
> context creation and while the classic drivers set the max_gl*version
> according to their capabilities, gallium uses fixed values which
> are not the best approach due to driver differences.
> 
> Add pipe-caps so that each driver can provide their individual capabilites.
> 
> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
> ---
>  src/gallium/docs/source/screen.rst   | 8 +++++++-
>  src/gallium/include/pipe/p_defines.h | 6 +++++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst
> index bd553f4..7b72133 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -169,7 +169,7 @@ The integer capabilities:
>    since they are linked) a driver can support. Returning 0 is equivalent
>    to returning 1 because every driver has to support at least a single
>    viewport/scissor combination.  
> -* ''PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
> +* ``PIPE_CAP_ENDIANNESS``:: The endianness of the device.  Either
>    PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE.
>  * ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
>    different sizes for fb color/zs attachments. This controls whether
> @@ -182,6 +182,12 @@ The integer capabilities:
>    vertex components output by a single invocation of a geometry shader.
>    This is the product of the number of attribute components per vertex and
>    the number of output vertices.
> +* ``PIPE_CAP_MAX_GL_CORE_VERSION``: The maximum OpenGL (Core profile) version
> +  supported.
> +* ``PIPE_CAP_MAX_GL_COMPAT_VERSION``: The maximum OpenGL (Compatibility profile)
> +  version supported.
> +* ``PIPE_CAP_MAX_GL_ES1_VERSION``: The maximum OpenGL ES1 version supported.
> +* ``PIPE_CAP_MAX_GL_ES2_VERSION``: The maximum OpenGL ES2 version supported.
>  
>  
>  .. _pipe_capf:
> diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
> index 83815cd..5c27f9c 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -522,7 +522,11 @@ enum pipe_cap {
>     PIPE_CAP_MIXED_FRAMEBUFFER_SIZES = 86,
>     PIPE_CAP_TGSI_VS_LAYER = 87,
>     PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES = 88,
> -   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89
> +   PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 89,
> +   PIPE_CAP_MAX_GL_CORE_VERSION = 90,
> +   PIPE_CAP_MAX_GL_COMPAT_VERSION = 91,
> +   PIPE_CAP_MAX_GL_ES1_VERSION = 92,
> +   PIPE_CAP_MAX_GL_ES2_VERSION = 93,
>  };
>  
>  #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
> 

Hmm do you really need all these different cap bits? Generally, the
difference between ES/CORE/COMPAT contexts isn't hw related at all, and
thus not really (gallium) driver related. So, obviously, every driver
can do ES11 for instance, it should be impossible to write a gallium
driver which can't. Similarly, I don't think core/compat needs a
different query neither, though I guess ES2 version being separate might
make sense.

Roland


More information about the mesa-dev mailing list