[Mesa-dev] [PATCH] Mesa: Return GL error INVALID_OPERATION in case invalid format/type

[Ilia Mirkin]

On Tue, Dec 13, 2016 at 8:56 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On Tue, Dec 13, 2016 at 4:28 AM, Randy Xu <randy.xu at intel.com> wrote:
>> From: "Xu,Randy" <randy.xu at intel.com>
>
> Please configure your name properly:
>
> git config --global user.name "Randy Xu"
>
>>
>> Refer to GLES3.2 spec in 8.5
>> Textures with a base internal format of DEPTH_COMPONENT, DEPTH_-
>> STENCIL or STENCIL_INDEX are supported by texture image specification
>> commands only if target is TEXTURE_2D, TEXTURE_2D_MULTISAMPLE,
>> TEXTURE_2D_ARRAY, TEXTURE_2D_MULTISAMPLE_ARRAY, TEXTURE_CUBE_-
>> MAP or TEXTURE_CUBE_MAP_ARRAY. Using these formats in conjunction with
>> any other target will result in an INVALID_OPERATION error.
>> This patch can fix dEQP-GLES3.functional.negative_api.texture.teximage3d
>> failure.
>>
>> Jira: https://01.org/jira/browse/AIA-9
>
> I work at Intel and I don't even know how to log into this. We really
> want publicly accessible links.
>
> Wemake an exception for internal Khronos bug reports, since lots of
> people have access, but I don't think Jira on 01.org is an exceptional
> case.
>
> Perhaps link to a freedesktop.org bug?
>
>>
>> Test: Pass dEQP-GLES3.functional.negative_api.texture.* and no
>> regression.
>
> That's not necessary.
>
>>
>> Signed-off-by: Xu,Randy <randy.xu at intel.com>
>> ---
>>  src/mesa/main/glformats.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
>> index a95909c..eeee66b 100644
>> --- a/src/mesa/main/glformats.c
>> +++ b/src/mesa/main/glformats.c
>> @@ -2087,6 +2087,8 @@ _mesa_error_check_format_and_type(const struct gl_context *ctx,
>>           else if (ctx->Extensions.ARB_depth_buffer_float &&
>>               type == GL_FLOAT_32_UNSIGNED_INT_24_8_REV)
>>              return GL_NO_ERROR;
>> +         else if (!_mesa_is_desktop_gl(ctx))
>
> I looked at the GL 4.5 spec, and it contains effectively the same wording.
>
> Please find when this changed, and then lets decide whether this is a
> "clarification" (i.e., intended behavior on all previous versions) or
> an actual change in behavior.

Something analogous happened in e.g. commit
19f13b2096a9fdd986e5a12d4e9d8b0d6a4632f3 (but I seem to recall a lot
of other instances of this type of thing, but I just can't find them).

  -ilia