mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.

ES3-CTS.functional.negative_api.buffer.framebuffer_texture2d expects
glFramebufferTexture[123]D to raise GL_INVALID_ENUM when
supplied a completely bogus textarget parameter (i.e. 0xffffffff).

This is at odds with the spec.  GLES 3.1 says:

   "An INVALID_OPERATION error is generated if texture is not zero and
    textarget is not one of TEXTURE_2D, TEXTURE_2D_MULTISAMPLE, or one
    of the cube map face targets from table 8.21."

(and GLES 3.0 and GL 4.5 both have similar text).  However, GL has a
general guideline that says:

   "If a command that requires an enumerated value is passed a symbolic
    constant that is not one of those specified as allowable for that
    command, an INVALID_ENUM error is generated."

Apparently other vendors reconcile these two rules as follows: GL should
raise INVALID_OPERATION for actual texture target enumeration values
which are not allowed for this particular glFramebufferTexture*D call.
Any value that is not a texture target should result in GL_INVALID_ENUM.

For example, glFramebufferTexture2D with GL_TEXTURE_1D would result in
INVALID_OPERATION because it is a real texture target, but not allowed
for the 2D version of the function.  But calling it with GL_FRONT would
result in INVALID_ENUM, as that isn't even a texture target.

Fixes:
- {ES3-CTS,dEQP-GLES3}.functional.negative_api.buffer.framebuffer_texture2d
- {ES31-CTS,ES32-CTS,dEQP-GLES31}.functional.debug.negative_coverage.get_error.buffer.framebuffer_texture2d

References: https://gitlab.khronos.org/opengl/cts/merge_requests/387
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>

0 files changed, 0 insertions, 0 deletions