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

[Chad Versace]

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.

>
>>> 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.