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

[Ian Romanick]

On 02/20/2015 08:13 AM, Eduardo Lima Mitev wrote:
> 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."

This language is intentionally loose.  It is often perfectly safe to
have a portion of a buffer mapped while a GL command operates on a
different part of the buffer.  Determining whether a particular
operation is safe can be expensive.  Imagine trying to determine whether
a glDrawElements command will source data from a mapped region of a
vertex buffer object.  Many vendors objected to having to put expensive
(or cheap) checks in performance critical paths.

I don't think an of the TexSubImage commands are performance critical
enough to warrant excluding the test.  I believe some benchmarks use
some of the TexSubImage commands, so it's probably worth measuring them
on, say, Baytrail with and without the checks.  My expectation is that
there's enough CPU wasted in those paths that the checks will be lost in
the noise.  We won't know until we measure.

> 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.

I'm also inclined to think they are wrong... or at least overly strict.

Do you know of any commands that require this error be generated?

> 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?

Looking at that function, I find it odd that either of the errors it
generates are generated there.  We should either do these checks in a
single, common place, or we should not do them at all.

> cheers,
> Eduardo
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>