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

Mon Feb 24 12:43:20 PST 2014

Am 24.02.2014 21:23, schrieb Marek Olšák:
> 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.
Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c
could be done without a context, as well as what mesa's compute_version
then does with it.
And yes you'd still need to clamp it to whatever the state tracker
actually supports (which is ugly since you can build mesa with non-gl
state trackers so querying the drivers that way ultimately makes not
much sense).
I'm not really against a gl version cap bit cause it looks like it would
be a pain otherwise, just pointing out that fundamentally this is really
a bit of a hack.

Roland


> 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 
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=Nafl1hYxTcSqVZR0trXfScdg%2F4Z6waunF1Q0gFcW5Vo%3D%0A&s=035abf3c02404885bea070547eb4f0a7c86b4cabfa099509088c858e5953d8c2