[Mesa-dev] [PATCH 05/11] mesa: Validate internal format and format type first to provide accurate error code

[Anuj Phogat]

On Tue, Jan 27, 2015 at 9:09 AM, Eduardo Lima Mitev <elima at igalia.com> wrote:
> On 01/21/2015 03:26 AM, Anuj Phogat wrote:
>> On Mon, Jan 19, 2015 at 3:32 AM, Eduardo Lima Mitev <elima at igalia.com> wrote:
>>> The specification states that glTexImage2D and glTexImage3D should return
>>> GL_INVALID_VALUE if the internal format is invalid, and GL_INVALID_ENUM is
>>> the format type is invalid. However, current error check only considers the
>>> combination of format, type and internal format; which returns a
>>> GL_INVALID_OPERATION error when invalid.
>>>
>> I did a quick search in es 3.0.4 spec but couldn't find the reference. Could you
>> point me to the reference in the spec and may be add it as a comment in the
>> code?
>>
>
> Hi,
>
> This behavior is described in the man pages, not any specification, so
> it is a mistake. I thoroughly reviewed GLES 3.0.0, 3.0.4, 3.1 and 2.0
> (just in case) and there is no explicit mention to this behavior.
>
> The closest I could find was this text in section 8.5. TEXTURE IMAGE
> SPECIFICATION (page 203) of the OpenGL 4.5 spec:
>
>     "An INVALID_VALUE error is generated if internalformat is not one of
> the valid values described above."
>
> (And "above" there is a large definition of all the valid internal
> formats, combinations, etc).
>
> So I wonder if there is an implicitly defined behavior that would
> justify this wording in the man page for TexImage3D/2D:
>
> * GL_INVALID_ENUM is generated if type is not a type constant.
> * GL_INVALID_VALUE is generated if internalFormat is not one of the
> accepted resolution and format symbolic constants.
>
> I know that the man pages are not a reliable source to define API
> behavior, but since apparently many dEQP tests are written against the
> man pages, it would be useful to understand better the link (if exists)
> between the man pages and the corresponding wording in a specification.
>
None of the tests in Khronos ES 3.0 CTS expect above errors. I think a
Khronos bug can be raised asking for clarification. Then we'll know it's
an issue with dEQP tests.

> I will withdraw this patch in the mean time.
>
> Thank you,
> Eduardo
>
>>> Fixes 2 dEQP tests:
>>> * dEQP-GLES3.functional.negative_api.texture.teximage2d
>>> * dEQP-GLES3.functional.negative_api.texture.teximage3d
>>> ---
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev