[Mesa-dev] [PATCH 5/5] mesa: compute the GLSL version in the core

Marek Olšák maraeo at gmail.com
Mon Jan 23 15:05:24 PST 2012


On Mon, Jan 23, 2012 at 10:35 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 01/23/2012 05:54 AM, Brian Paul wrote:
>>
>> On Sun, Jan 22, 2012 at 4:36 PM, Marek Olšák<maraeo at gmail.com>  wrote:
>>>
>>> I think the CAP-based approach is the way to expose GLSL 1.3 for st/mesa.
>>> The later GLSL versions can be easily derived from exposed extensions,
>>> it's just GLSL 1.3 that is tricky. Comments welcome.
>>> ---
>>>  src/mesa/drivers/dri/intel/intel_extensions.c  |    9 +--
>>>  src/mesa/drivers/dri/intel/intel_screen.c      |    2 +-
>>>  src/mesa/drivers/dri/nouveau/nouveau_context.c |    2 +-
>>>  src/mesa/drivers/dri/r200/r200_context.c       |    2 +-
>>>  src/mesa/drivers/dri/radeon/radeon_context.c   |    2 +-
>>>  src/mesa/main/context.c                        |   14 +----
>>>  src/mesa/main/mtypes.h                         |    9 +++
>>>  src/mesa/main/version.c                        |   76
>>> ++++++++++++++++++++++--
>>>  src/mesa/main/version.h                        |    5 +-
>>>  src/mesa/state_tracker/st_extensions.c         |   40 ++++++-------
>>>  src/mesa/state_tracker/st_manager.c            |    2 +-
>>>  11 files changed, 109 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
>>> b/src/mesa/drivers/dri/intel/intel_extensions.c
>>> index 0ce452f..f9caeee 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_extensions.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
>>> @@ -90,11 +90,10 @@ intelInitExtensions(struct gl_context *ctx)
>>>    ctx->Extensions.OES_EGL_image = true;
>>>  #endif
>>>
>>> -   if (intel->gen>= 6)
>>> -      ctx->Const.GLSLVersion = 130;
>>> -   else
>>> -      ctx->Const.GLSLVersion = 120;
>>> -   _mesa_override_glsl_version(ctx);
>>> +   if (intel->gen>= 6) {
>>> +      ctx->Const.NativeIntegerResources = GL_TRUE;
>>> +      ctx->Const.ShadowCubeSamplers = GL_TRUE;
>
>
> Here's the problem with cap bits in general.  On GEN4 through GEN5 we
> support native integer resources and shadow cube samplers.  We don't support
> 1.30 on those platforms because of clip distance and the new interpolation
> qualifiers.  If the other capabilities aren't used for other things
> internally (allowing meta ops to use different paths, etc.), I don't see any
> utility having a big pile of bits whose only purpose is to enable one
> feature.

Well, yeah, you're right. There's not much point in having a pile of
caps for the same purpose. I'll add PIPE_CAP_GLSL_FEATURE_LEVEL
(== GLSLVersion) then. The D3D shader models and feature levels are
totally useless for expressing OpenGL features, so I can't use those.

Marek


More information about the mesa-dev mailing list