[Mesa-dev] glCompressedTex(Sub)Image(2,3) on mapped PBOs

[Eduardo Lima Mitev]

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