On 02/07/2013 07:01 PM, Ian Romanick wrote:
On 02/07/2013 05:54 PM, Paul Berry wrote:
In the documentation for BindBufferRange, OpenGL specs from 3.0
through 4.1 contain this language:

     "The error INVALID_VALUE is generated if size is less than or
     equal to zero or if offset + size is greater than the value of
     BUFFER_SIZE."

This text was dropped from OpenGL 4.2, and it does not appear in the
GLES 3.0 spec.

Presumably the reason for the change is because come clients change
the size of the buffer after calling BindBufferRange.  We don't want
to generate an error at the time of the BindBufferRange call just
because the old size of the buffer was too small, when the buffer is
about to be resized.

Since this is a deliberate relaxation of error conditions in order to
allow clients to work, it seems sensible to apply it to all versions
of GL, not just GL 4.2 and above.

(Note that there is no danger of this change allowing a client to
access data beyond the end of a buffer.  We already have code to
ensure that that doesn't happen in the case where the client shrinks
the buffer after calling BindBufferRange).

Eliminates a spurious error message in the gles3 conformance test
"transform_feedback_offset_size".
---
  src/mesa/main/bufferobj.c | 7 -------
  1 file changed, 7 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 7c06938..b82ba7b 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -2152,13 +2152,6 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
                       (int) size);
           return;
        }
-
-      if (offset + size > bufObj->Size) {
-         _mesa_error(ctx, GL_INVALID_VALUE,
-                     "glBindBufferRange(offset + size %d > buffer
size %d)",
-                     (int) (offset + size), (int) (bufObj->Size));
-         return;
-      }
     }

     switch (target) {


For some reason, this change makes one of the UBO tests fail... while
making the transform feedback tests not get an error.  Sigh... I'll look
in to it...

Stupid test... it looks like that test fails because we don't generate an error for an offset = 0 when our GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT is 1. However, I think GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT should not be 1. It looks like the Windows driver sets 16 (vec4 alignment, makes sense). I don't even know where to look for this in the bspec.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to