[Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
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]). Fortunately, when the extension was initially implemented, we already took into account most of the GL ES dependencies defined at the spec, so we don't need a lot of changes on mesa now. There are more on the piglit tests (I will send a series for piglit in short). So this series include two patches that provides the support of this extension in OpenGL ES: * [PATCH 4/5] mesa/glformats: add desktop gl checks on _mesa_base_tex_format * [PATCH 5/5] mesa/main: expose ARB_internalformat_query2 on ES2. The other three patches are not related with OpenGL ES, but I think that it is better/tidier to keep all the unreviewed patches for ARB_internalformat_query2 on the same series. Two of those three were sent at the beginning of the month [5] (so it is technically a re-send). As mentioned, I will send in short a equivalent series for piglit. It is worth to mention that with this series there will be two deqp tests that will start to fail: * deqp-gles3@functional@negative_api@state@get_internalformativ * deqp-gles31@functional@debug@negative_coverage@get_error@state@get_internalformativ And two warnings: * deqp-gles31@functional@debug@negative_coverage@callbacks@state@get_internalformativ * deqp-gles31@functional@debug@negative_coverage@log@state@get_internalformativ This is caused because those tests are checking that GetInternalformativ returns error for some pname/target/internalformat that were wrong with query1 but are not anymore with query2. I provided patches to solve this problem [6][7] Best regards [1] https://lists.freedesktop.org/archives/mesa-dev/2016-February/106397.html [2] https://lists.freedesktop.org/archives/mesa-dev/2016-March/108956.html [3] https://www.opengl.org/registry/specs/ARB/internalformat_query2.txt [4] https://www.khronos.org/bugzilla/show_bug.cgi?id=1496 [5] https://lists.freedesktop.org/archives/mesa-dev/2016-May/115736.html [6] https://android-review.googlesource.com/#/c/229484/ [7] https://android-review.googlesource.com/#/c/229485/ Alejandro Piñeiro (5): i965/formatquery: remove INTERNALFORMAT_PREFERRED implementation mesa/formatquery: add a comment to clarify INTERNALFORMAT_PREFERRED mesa/formatquery: expand NUM_SAMPLE_COUNTS OpenGL ES comment mesa/glformats: add desktop gl checks on _mesa_base_tex_format mesa/main: expose ARB_internalformat_query2 on ES2. src/mapi/glapi/gen/ARB_internalformat_query2.xml | 2 +- src/mesa/drivers/dri/i965/brw_formatquery.c | 71 -- src/mesa/main/extensions_table.h | 2 +- src/mesa/main/formatquery.c | 8 ++- src/mesa/main/glformats.c| 76 +++- 5 files changed, 71 insertions(+), 88 deletions(-) -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
On Fri, May 13, 2016 at 10:57 AM, Alejandro Piñeiro 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. -ilia > > Fortunately, when the extension was initially implemented, we already > took into account most of the GL ES dependencies defined at the spec, > so we don't need a lot of changes on mesa now. There are more on the piglit > tests (I will send a series for piglit in short). > > So this series include two patches that provides the support of this > extension in OpenGL ES: > > * [PATCH 4/5] mesa/glformats: add desktop gl checks on _mesa_base_tex_format > * [PATCH 5/5] mesa/main: expose ARB_internalformat_query2 on ES2. > > The other three patches are not related with OpenGL ES, but I think > that it is better/tidier to keep all the unreviewed patches for > ARB_internalformat_query2 on the same series. Two of those three were > sent at the beginning of the month [5] (so it is technically a > re-send). > > As mentioned, I will send in short a equivalent series for piglit. It > is worth to mention that with this series there will be two deqp tests > that will start to fail: > * deqp-gles3@functional@negative_api@state@get_internalformativ > * > deqp-gles31@functional@debug@negative_coverage@get_error@state@get_internalformativ > > And two warnings: > * > deqp-gles31@functional@debug@negative_coverage@callbacks@state@get_internalformativ > * > deqp-gles31@functional@debug@negative_coverage@log@state@get_internalformativ > > This is caused because those tests are checking that > GetInternalformativ returns error for some pname/target/internalformat > that were wrong with query1 but are not anymore with query2. I > provided patches to solve this problem [6][7] > > Best regards > > [1] https://lists.freedesktop.org/archives/mesa-dev/2016-February/106397.html > [2] https://lists.freedesktop.org/archives/mesa-dev/2016-March/108956.html > [3] https://www.opengl.org/registry/specs/ARB/internalformat_query2.txt > [4] https://www.khronos.org/bugzilla/show_bug.cgi?id=1496 > [5] https://lists.freedesktop.org/archives/mesa-dev/2016-May/115736.html > [6] https://android-review.googlesource.com/#/c/229484/ > [7] https://android-review.googlesource.com/#/c/229485/ > > Alejandro Piñeiro (5): > i965/formatquery: remove INTERNALFORMAT_PREFERRED implementation > mesa/formatquery: add a comment to clarify INTERNALFORMAT_PREFERRED > mesa/formatquery: expand NUM_SAMPLE_COUNTS OpenGL ES comment > mesa/glformats: add desktop gl checks on _mesa_base_tex_format > mesa/main: expose ARB_internalformat_query2 on ES2. > > src/mapi/glapi/gen/ARB_internalformat_query2.xml | 2 +- > src/mesa/drivers/dri/i965/brw_formatquery.c | 71 -- > src/mesa/main/extensions_table.h | 2 +- > src/mesa/main/formatquery.c | 8 ++- > src/mesa/main/glformats.c| 76 > +++- > 5 files changed, 71 insertions(+), 88 deletions(-) > > -- > 2.7.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
On 13/05/16 17:06, Ilia Mirkin wrote: > On Fri, May 13, 2016 at 10:57 AM, Alejandro Piñeiro > 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. Yes, initially I also found strange this extension to be the only ARB_ extension to be exposed in ES. But there are too many OpenGL ES references and dependencies on the ARB_internalformat_query2 to be consider a mistake in the other way. So now doing a detailed list of references to OpenGL ES: * From the list of dependencies at the beginning (line 42), it list the following extensions: * OES_texture_3D (line 51) * OES_depth_texture(line 60) * Then it gives further details about the OpenGL ES dependencies inside the document: * Dependencies on OpenGL ES 2.0 (line 850): list valid targets/pnames for OpenGL ES 2.0 * Dependencies on OES_texture_3D (line 876) * Dependencies on OpenGL ES 3.0 (line 879): list valid targets/pnames for OpenGL ES 3.0 * Dependencies on ARB_depth_texture and OES_depth_texture (line 1063) * Additionally, OpenGL ES is mentioned on the Overview. Quoting (line 89) "While much of this information can be determined for a single GL version by careful examination of the specification, support for many of these properties has been gradually introduced over a number of API revisions. This can observed when considering the range in functionality between the various versions of GL 2, 3, and 4, as well as GL ES 2 and 3. In the case of an application which wishes to be scalable and able to run on a variety of possible GL or GL ES versions without being specifically tailored for each version, it must either have knowledge of the specifications built up into either the code or tables, or it must do a number of tests on startup to determine which capabilities are present." From all those reference, my conclusion is that this extension should be also supported on OpenGL ES. About the extension number: good point. I didn't realize about that. For EXT_ extensions that are supported on both OpenGL and OpenGL ES (like EXT_texture_sRGB_decode), it is true that define two extensions numbers, one for Open GL and other for Open GL ES. Note sure if it is needed for ARB extensions too. In any case, in case of being needed, at this point Im still convinced that query2 was intended to be available to OpenGL ES, so this is another minor bug on the extension, similar to the bug I opened for the registry gl.xml file, so a extension number for OpenGL ES would be needed. BR ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
On 13/05/16 17:06, Ilia Mirkin wrote: > On Fri, May 13, 2016 at 10:57 AM, Alejandro Piñeiro > 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 :/ BR ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
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 >> 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
Re: [Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
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 >>> 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
Re: [Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes
On 01/06/16 20:57, Ian Romanick wrote: > 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 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. Ok, thanks for the further explanation. BR ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
