On Tue, Sep 4, 2012 at 10:43 AM, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 09/01/2012 10:14 AM, Jordan Justen wrote: >> Change the format to [MAJOR.MINOR][CORE|COMPAT] >> For example: 3.0, CORE, COMPAT, 3.2CORE >> >> Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com> > > Since we aren't going to support compatibility contexts, I would just > make MESA_GL_VERSION_OVERRIDE=3.1 force API_OPENGL_CORE. It's simpler > to use and less code.
OVERRIDE=3.1 causing the API to automatically change seems a little unexpected to me. Would we really want to tie the lack of GL>=3.1 + compatibility into mesa in this way? > Plus, MESA_GL_VERSION_OVERRIDE=3.2COMPAT is completely useless right > now, as nothing supports it. If somebody did ever want to implement > compatibility mode (and I am strongly opposed to accepting such > patches), they could add this then. MESA_GL_VERSION_OVERRIDE lets you put mesa into various levels of strange/unsupported states already. :) I'd readily drop the 'COMPAT' part if requested, but I think it might be useful, and seems somewhat expected when 'CORE' is added. > There's one key semantic difference worth mentioning: previously, > MESA_GL_VERSION_OVERRIDE made the drivers lie and advertise support for > a particular version (even if they normally wouldn't). Now, I think > you're trying to change it so setting MESA_GL_VERSION_OVERRIDE=3.2CORE > makes it actually /give you/ a 3.2 core context. That seems useful, and > I agree with the change, I just wanted to point it out. With various ctx->Version checks in the code, the runtime behaviour of the driver can be altered in various ways when MESA_GL_VERSION_OVERRIDE is used today. This doesn't seem like much of a departure from that. -Jordan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
