Obsolete
Status Update
Comments
kr...@google.com <kr...@google.com> #2
I looked at https://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf . The section 3.7.1 on page 67 says:
"If internalformat does not match format, the error INVALID_OPERATION is generated."
and I believe this language is inherited by the TexSubImage2D definition. I.e., I believe I agree.
The patch might be incomplete, though. Looking at the code it appears to me that the same problem appears in other cases as well.
"If internalformat does not match format, the error INVALID_OPERATION is generated."
and I believe this language is inherited by the TexSubImage2D definition. I.e., I believe I agree.
The patch might be incomplete, though. Looking at the code it appears to me that the same problem appears in other cases as well.
kr...@google.com <kr...@google.com> #3
... although the following in Section 3.7.2, page 72, may hint that the internal format dominates:
"except that the assignment of R, G, B, and A pixel group values to the
texture components is controlled by the internalformat of the texture array, not
by an argument to the command".
I'll get a 2nd opinion on this.
"except that the assignment of R, G, B, and A pixel group values to the
texture components is controlled by the internalformat of the texture array, not
by an argument to the command".
I'll get a 2nd opinion on this.
kr...@google.com <kr...@google.com> #4
The 2nd option came back with same interpretation as you had. TexImage2D with RGBA followed by TexSubImage2D with RGB should lead to error.
sa...@google.com <sa...@google.com> #5
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
Description
dEQP-GLES2.functional.negative_api.texture.texsubimage2d_neg_offset
dEQP-GLES2.functional.negative_api.texture.texsubimage2d_offset_allowed
dEQP-GLES2.functional.negative_api.texture.texsubimage2d_neg_wdt_hgt
The 3 of them focus on validating the width/height or xoffset/yoffset arguments of glTexSubImage2D. However, they use an incorrect internal format in these calls, which makes them subject to fail depending on the order in which a certain OpenGL implementations performs the validations of format+type+internal format, versus the validation of dimensions. Such is the case of Mesa.
The 3 tests perform calls to glTexSubImage2D using format = GL_RGB and type = GL_UNSIGNED_BYTE, on a texture that has been initialized with GL_RGBA internal format.
Per table 3.16, section "3.8 Texturing", page 154 of the OpenGL ES 2.0 spec (PDF), the combination of format=GL_RGB, type=GL_UNSIGNED_BYTE and internalFormat=GL_RGBA is not valid.
I have attached a reference patch fixing the issue. I leave it to some AOSP contributor to take ownership of and apply it, if it is deemed correct, since I'm not a contributor myself.