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

[Roland Scheidegger]

----- Original Message -----
> From: "Emil Velikov" <emil.l.velikov at gmail.com>
> To: "Roland Scheidegger" <sroland at vmware.com>, mesa-dev at lists.freedesktop.org
> Cc: "emil l velikov" <emil.l.velikov at gmail.com>
> Sent: Saturday, February 22, 2014 2:02:08 PM
> Subject: Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps
> 
> On 22/02/14 12:02, Roland Scheidegger wrote:
> > 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.
> > 
> If you can think of a way to retrieve the gl* version that a driver
> support without ever having a gl_context I would love to hear how we can
> do that. GLX_MESA_query_renderer requires from the driver to state the
> version of each api it supports prior of context creation.
> 
> Honestly I felt a bit bad about adding all those caps, but this is the
> least evasive way of handling it. I will drop the ES1 cap would love to
> nuke the rest as well :-)


I think you could easily derive compat and core version from some "gl driver
version" instead of having two (the driver knows nothing about core or compat
contexts, after all). ES might be different (at least with OES 4.0).
But technically, you shouldn't even need any version queries as you could derive
this from all the other cap bits I think (much the same way as st_extensions.c
figures out what extensions are supported, plus mesa's compute_version then does).
None of that cap query stuff (including querying for msaa formats and the like)
requires a context. At least I can't see why it wouldn't work.

Roland