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 :-)
Emil
> Roland
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
