[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