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

[Ian Romanick]

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:
>>>>> Another possibility that Chad suggested when I was talking to him this
>>>>> afternoon is to just just return BAD_MATCH if the client supplies the
>>>>> forward-compatibility flag when requesting a 3.0+ context.  Rationale: Mesa
>>>>> doesn't really support the forward-compatibility flag anyhow (since the EGL
>>>>> and GLX front-ends just drop it on the floor), and besides we don't know of
>>>>> any shipping apps that require it (the flag is intended as a developer aid,
>>>>> so it's unlikely that published apps rely on it).  I don't have a really
>>>>> strong opinion about is, so I'll let Chad weigh in if he wants to champion
>>>>> this alternative.
>>>>
>>>> Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a forward-
>>>> compatible context. I don't believe we have the right balance of resources
>>>> and interest to properly implement and test support for the forward-compatible
>>>> flag. No one users are asking for it, and it's likely nearly no one will use it.
>>>> The future may change this situation, but that's a big 'may'.
>>>
>>> KWin always sets the forward-compatible bit in 4.11, but it's not too late
>>> to change that. It appears to be accepted by all implementations and has
>>> no negative side effects, so there was no compelling reason to leave it
>>> out in a release build.
>>
>> For what GL context versions does KWin set the forward-compatible bit?
>> For 3.0 only? For all versions >= 3.0? For that matter, what context
>> versions does KWin request?
>
> It first tries to create a 3.1 forward-compatible context. If that fails,
> it tries to create a context with the version set to 1.2, and without
> the forward-compatible bit set.
>
> 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.

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

> In practice it seems that both Mesa and the NVIDIA driver ignores
> the flag though, which I guess is a good reason not to set it.

If you know specific cases where we do the wrong thing, I'd like to have 
bug reports.  I think we figured out that we've totally botched the GLSL 
side, but I think the API side /should/ be correct.

> Fredrik
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev