On Mon, Aug 21, 2017 at 12:52 AM, Harish Krupo <harish.krupo....@intel.com> wrote: > Hi Ilia, > > On 08/18/2017 07:20 PM, Ilia Mirkin wrote: >> >> Why the static data changes? Also, I haven't double checked the code, but >> I'm almost certain this is incomplete. You have to add code disallowing the >> other enums from being used on es2. > > > Thank you for pointing out that code is required to disallow usage of other > enums in gles2. When adding code to check for gles2 context I ran into an > other issue. The issue was that when one requests mesa for a gles2 context, > it actually returns a gles3.1 context. So if the code checks for an es2 > context, it will return false and the enums will be allowed. Could you > suggest a way out of this?
Contexts are upgraded automatically -- this is allowed by the spec. You could run with MESA_GLES_VERSION_OVERRIDE=2.0 to force it though. Also one has to ask the question of whether the *EXT functions should allow the enums that have been added to the core ES functions. I suspect so, but it's a reasonable question. > > As for the static data changes, I wasn't exactly sure of the file's usage, I > saw that the ARB versions of the functions were also present, so I added it > there. If it is not required, I will remove it in the next version of the > patch. Could you please explain why it is not needed? I honestly don't remember all the logic. You'll need to work out what it's for -- as I recall there are comments. Maybe it affects the list of exposed symbols for linking, which this does not need to be one of. But maybe it's for something dispatch-table-related, in which case it may be necessary. I do know it's not *always* necessary though. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
