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

[Chad Versace]

On 07/11/2013 10:18 PM, Paul Berry wrote:
> On 11 July 2013 16:30, Ian Romanick <idr at freedesktop.org> wrote:


> I believe you're right, that there's a bug in our implementation--it would
> successfully compile this shader, and it shouldn't.
>
> In fact, based on my discussion with Chad today, it sounds like we don't
> have any code at all to modify Mesa's behaviour when the forward-compatible
> flag is in effect--my understanding is that the EGL and GLX DRI front-ends
> just drop that flag on the floor.  So to fix the bug we would have to do
> some plumbing work to get the flag through DRI to Mesa's gl_context.

I just verified this with an example EGL program. Mesa's EGL layer passes the
forward-compatible flag to the DRI layer, and DRI ignores it.


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