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.
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
