Hello, While working on the following dEQP failing tests I ran into an issue that I think deserves clarification from more experienced people:
dEQP-GLES3.functional.negative_api.texture.compressedteximage2d_invalid_buffer_target dEQP-GLES3.functional.negative_api.texture.compressedtexsubimage2d_invalid_buffer_target dEQP-GLES3.functional.negative_api.texture.compressedteximage3d_invalid_buffer_target dEQP-GLES3.functional.negative_api.texture.compressedtexsubimage3d_invalid_buffer_target All above tests fail because a CompressedTex(Sub)Image(2,3)D operation is performed while there is a pixel buffer object bound to GL_PIXEL_UNPACK_BUFFER and that pixel buffer object is currently mapped. The tests expect this situation to throw an GL_INVALID_OPERATION but no error is returned on i965. In the spec GLES 3.1 spec, page 57, there is this: (and similar wording in GL 4.5 spec, page 76) "6.3.2 Effects of Mapping Buffers on Other GL Commands "Any GL command which attempts to read from, write to, or change the state of a buffer object may generate an INVALID_OPERATION error if all or part of the buffer object is mapped. However, only commands which explicitly describe this error are required to do so. If an error is not generated, using such commands to perform invalid reads, writes, or state changes will have undefined results and may result in GL interruption or termination." There is no further restriction in gl(Compressed)Tex(Sub)Image(2,3)D that makes throwing an error mandatory, hence I suspect these tests might be wrong. However, I found that glTex(Sub)Image(2,3)D do emits an GL_INVALID_OPERATION error when executed while a mapped PBO is bound. But the check is performed in driver code (as opposed to API entry points). (Concretely, in i965/intel_tex_image.c::intelTexImage() and i965/intel_tex_subimage.c::intelTexSubImage() which both call common/meta_tex_subimage.c::_mesa_meta_pbo_TexSubImage()). So, the question is: Shouldn't these operations on compressed texture images have the same restriction as their non-compressed counter-parts? Or is there a reason why this restriction is enforced only on non-compressed images? Also, shouldn't this restriction be moved to common API entry points, or are there drivers that do write to PBOs while they are mapped? cheers, Eduardo _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev