On 06/01/2016 11:35 AM, Alejandro Piñeiro wrote: > 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
I believe the decision was to remove OpenGL ES from the extension. The extension was originally targeted as KHR, but, for reasons I don't recall, that didn't work out. The bits in the spec about OpenGL ES were just leftovers from that. > 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
