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

[Jason Ekstrand]

On Fri, Feb 20, 2015 at 8:13 AM, Eduardo Lima Mitev <elima at igalia.com>
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."
>
> 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?
>

IMHO, that's exactly what we need to do.  I've been toying with writing a
patch to do just that.  Right now, we're leaving checking if the buffer is
mapped and checking if it has enough size up to the device-specific driver
backend.  This is, in general, not how the rest of mesa does error-checking
so it seems very odd.  Also, it means that if a driver misses the check it
causes a GL API failure not just a texture upload error.  To make it worse,
they all check it by calling the same function inside mesa/main so there's
really no excuse.  I haven't seen any good reason why we aren't just
calling that in the error-checking section of the entry-point.

--Jason


> cheers,
> Eduardo
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150220/9071820e/attachment.html>