Running the following case list: dEQP-GLES3.functional.negative_api.buffer.clear dEQP-GLES3.functional.negative_api.shader.compile_shader dEQP-GLES3.functional.negative_api.shader.delete_shader causes compile_shader and delete_shader to fail. The problem is that buffer.clear produces Meta shaders, and compile_shader/delete_shader see those. We correctly identify them as internal shaders, but always return INVALID_OPERATION, while the test expects INVALID_OPERATION or INVALID_ENUM.
Actually, the problem is that compile_shader's first subtest assumes that no shaders exist, i.e. glCompileShader(9) should return GL_INVALID_VALUE because 9 simply does not exist. But because of Meta, it does exist - and the real bug is that applications can observe and even alter these shaders. In the dEQP test sequence, it happens to be a gl_shader_program, so we return GL_INVALID_OPERATION. But it could be a shader, at which point we would return it.
I have patches to fix this.
commit 9c1e01c4a883ac4a738f6f8c17c0236621101e28 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Tue Mar 15 10:51:55 2016 -0700 meta: Don't use integer handles for shaders or programs. and the previous patches.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.