[Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.

[Ian Romanick]

On 07/15/2013 02:14 PM, Chad Versace wrote:
> On 07/15/2013 02:05 PM, Ian Romanick wrote:
>> On 07/15/2013 06:26 AM, Fredrik Höglund wrote:
>>> On Friday 12 July 2013, Chad Versace wrote:
>>>> On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
>>>>> On Friday 12 July 2013, Chad Versace wrote:
>>>>>> On 07/11/2013 10:18 PM, Paul Berry wrote:
>
>>> There are currently no real functional differences between the 3.1
>>> and the 2.x paths in KWin. The main motivation for adding the option
>>> to create a 3.1 context was the thinking at the time that Mesa would
>>> only enable threaded dispatch in a core context.
>>
>> core context != forward-compatible context
>>
>> Just requesting OpenGL 3.1 would have been sufficient.
>
> Just requesting OpenGL 3.1 would have been sufficient for Mesa, because
> it no
> Mesa driver creates an GL 3.1 context with the GL_ARB_compatibility
> extension.
> But, according to the spec, implementations are allowed to return a GL
> 3.1 context
> *with or without* the GL_ARB_compatibility extension when the user
> requests a 3.1
> context. So, the only way to ensure that your 3.1 context won't have
> GL_ARB_compatibility is
> to request a context with the forward-compatible bit.

Right... but he was talking about using that to get at some other 
Mesa-specific feature... that we never finished. :)

>>>> Why does KWin set the forward-compatible bit? There must be some
>>>> motivation
>>>> for that, other than "the button is there so let's push it".
>>>
>>> It's to ensure that we're not using deprecated features in the 3.x
>>> paths,
>>> and more importantly that no one introduces new code that uses
>>> deprecated features.
>>
>> That's a good idea for debug builds, but I'm not so sure about release
>> builds.  Hmm...
>
> I concur. I think it would be wise to enable that flag only for
> development builds.
>