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

[Fredrik Höglund]

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.

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

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.

Fredrik