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

Mon Feb 24 13:08:03 PST 2014

On 24/02/14 20:43, Roland Scheidegger wrote:
> 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.
> 
It's not just "a bit" it's a decent sized one, but my main concern is
that doing that alone will result in a delta exceeding this whole series
by a magnitude of two if not more.

That would require some time which I can not spare in the next few weeks.

FWIW the intel guys landed support for the extension in mesa 10.0, and
it would be nice if everyone else can have it in time for 10.2.

-Emil
> 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