On 06/26/2015 01:06 AM, Ilia Mirkin wrote:
On Thu, Jun 25, 2015 at 4:22 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
On Thu, Jun 25, 2015 at 5:08 AM, Marta Lofstedt
<marta.lofst...@linux.intel.com> wrote:
From: Marta Lofstedt <marta.lofst...@intel.com>
v4 : only expose GL_ARB_texture_multisample enums
for gles 3.1 and desktop GL.
I was suspicious of this logic. Based on my reading of the code, what
your ARB_texture_multisample_es31 thing does is expose those enums
when *either* the driver enables ARB_texture_multisample *or* the
current context is ES3.1.
ARB_draw_indirect_es31 has the same problem, btw.
I'm not sure I understand the issue. It should work fine with 'OR', if
we have either of these then we expose the enum?
I could have misread the get.c extra_ext() logic, but I don't think I
have. As far as I can tell there's no way to (generically) AND these
things.
Why do we need AND? If you have 3.1 context then you *need* to support
this enum. There is no such condition where you would have gles 3.1
context but not the enum, right?
What you really need to do is create a whole new [GL, GL_CORE, ES31]
section in get_hash_params and update get_hash_generator.py
accordingly.
An alternative, BTW, is to just say "screw it" and expose the enums in
GL ES 3.0. In that case, just move the enums into a section that
includes GLES3. I'm not sure how big of a deal it is. But your current
patches are definitely wrong.
We do this, but we have explicit version check against version 3.1.
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
