On Friday 12 July 2013, Chad Versace wrote:
> On 07/12/2013 12:25 PM, Fredrik H=F6glund 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 t=
he EGL
> >>> and GLX front-ends just drop it on the floor), and besides we don't k=
now of
> >>> any shipping apps that require it (the flag is intended as a develope=
r aid,
> >>> so it's unlikely that published apps rely on it).  I don't have a rea=
lly
> >>> strong opinion about is, so I'll let Chad weigh in if he wants to cha=
mpion
> >>> this alternative.
> >>
> >> Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a for=
ward-
> >> compatible context. I don't believe we have the right balance of resou=
rces
> >> and interest to properly implement and test support for the forward-co=
mpatible
> >> flag. No one users are asking for it, and it's likely nearly no one wi=
ll 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 l=
ate
> > 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 >=3D 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 motivati=
on
> 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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev