Am 23.02.2014 16:26, schrieb Emil Velikov:
> On 22/02/14 21:46, Roland Scheidegger wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Emil Velikov" <emil.l.veli...@gmail.com>
>>> To: "Roland Scheidegger" <srol...@vmware.com>,
>>> mesa-dev@lists.freedesktop.org
>>> Cc: "emil l velikov" <emil.l.veli...@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.veli...@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.
>>
> Now that I think about it, one could copy the extension list and
> (context) constants to pipe_screen. This way on st_api_create_context,
> we'll just copy the initial values over. FWIW we'll still be able to
> amend the extension list via MESA_EXTENSION_OVERRIDE, during the
> _mesa_make_current call.
>
> ... or should I scrap this idea, and retrieve the extensions only to
> discard them after the version is determined ?
>
> Either way the core/compat version will look rather hacky, imho, but
> other places of mesa seem to be using the same approach so I'll stick
> with it.
>
> if version > 31 {
> core = version;
> compat = 30;
> } else {
> core = 0;
> compat = version;
> }
>
>
> Roland do you had something similar in mind or am I completely off from
> what you're saying ?
>
Yes that's what I had in mind if you really want to have a version query
and not determine that from all the other caps.
Roland
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
