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

Mon Feb 24 12:23:30 PST 2014

Roland,

The version CAPs that Emil wants to add have very little to do with
which features a driver supports. The versions cannot be derived from
other CAPs, instead, it should match what you get after you create an
OpenGL context. For example, if your driver can do GL 4.0, the driver
cannot report that it can do 4.0. Instead, it should say it can do
3.3, because that's what core Mesa can do. The only purpose of these
new version CAPs is to match what core Mesa does without asking core
Mesa. It's ugly, but it's the least invasive solution.

Of course, it can actually be done cleanly, e.g. making both
main/version.c and st_extensions.c independent of gl_context and only
using a DRI screen or something like that, but that needs a lot more
work.

Marek

On Sat, Feb 22, 2014 at 10:46 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>
>
> ----- 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev