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