On 13/05/16 23:20, Alejandro Piñeiro wrote: > > On 13/05/16 17:06, Ilia Mirkin wrote: >> On Fri, May 13, 2016 at 10:57 AM, Alejandro Piñeiro >> <apinhe...@igalia.com> wrote: >>> Earlier this year the support for ARB_internalformat_query2 has landed >>> [1][2], initially only for desktop GL. >>> >>> But looking more carefully to the spec [3], we found the following: >>> >>> "Dependencies >>> >>> OpenGL 2.0 or OpenGL ES 2.0 is required" >>> >>> Note the *or*. Additionally the spec list other GL ES 2.0/3.0 >>> dependencies. So that means that the extension can be also applied to >>> GL ES 2.0/3.0. FWIW, this mistake is common, as it also happens with >>> the khronos registry xml (khronos bug created [4]). >> Are you sure it's not a mistake the other way? There's no ES extension >> number allocated, and no vendor drivers expose this ext on ES, and >> this would be the first GL_ARB_* ext to be exposed in ES... normally >> these become GL_OES_bla or GL_KHR_bla. > Seems that you were right: > https://www.khronos.org/bugzilla/show_bug.cgi?id=1498#c1 > > Although then I don't understand why ARB_internalformat_query2 has those > dependencies to OpenGL ES 2.0/3.x and OES extensions: > https://www.khronos.org/bugzilla/show_bug.cgi?id=1498#c2
I didn't get an answer to my last questions on the khronos bug. Taking into account IRC comments, it is usual to be slow. In any case, the first answer seems to be clear, and ARB_ extensions are not intended to be exposed on OpenGL ES, and it seems that ARB_internalformat_query2 is not an exception, even if the specification defines the behaviour of the extension for OpenGL ES2/ES2. So at this point, we should just move forward. In my opinion we should just forget about the patch5 of the series, the one that exposes the extension, and we should review and push the first 4 patches: * patch1 and patch2 affects desktop gl too (fixes some cases for INTERNALFORMAT_PREFERRED) * patch3 just expands a comment * patch4 makes _mesa_base_tex_format to take into account opengl es too: although it was implemented just for the needs of this extension, I still think that it makes sense to do that. And after all, that method already have some OpenGL ES checks. The patch just add more of them. In any case, this is somewhat more optional. Opinions? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
