[Mesa-dev] [PATCH 0/5] ARB_internalformat_query2 support for OpenGL ES and other fixes

[Ian Romanick]

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
>>> <apinheiro at 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?