On 06/27/2012 12:01 PM, Eric Anholt wrote:
How should glBindBufferBase and glBindBufferRange treat bad buffer
arguments? I see two relevant pieces of spec:
"The error INVALID_OPERATION is generated by BindBufferRange and
BindBufferBase if<buffer> is not the name of a valid buffer
object."
and
"(60) When using this extension with OpenGL 2.1/3.0, do we require
that uniform buffer object names must be generated with glGenBuffers
to be used with these new entry points?
For OpenGL 3.1 core, there is a blanket requirement to call glGen
for object names.
For OpenGL 2.x, there is not a requirement to call glGen but in
3.0, user-generated names have been deprecated.
For 3.0, we added two new object types (FBO/VAO) that
required the user to call glGen, but existing object types
(textures/renderbuffers/buffer objects) could be used
without calling glGen.
We need to decide what to do with this when exporting
this extension on 2.1 and 3.0.
RESOLUTION: Resolved, this extension does not govern the creation of
buffer objects. That's done by BindBuffer, which is not altered
by this spec, so on 2.1 and 3.0 you'd be able to use any name,
whereas on 3.1 you'd be required to call GenBuffers."
Does this mean that only glBindBuffer does the automatic Gen behavior,
and not glBindBufferBase or glBindBufferRange? That seems strange. If
so, how about if the buffer has been Genned but not glBindBuffer()ed yet
-- is it still a bad argument? Also, note that EXT_transform_feedback
doesn't specify the error for<buffer> not being a valid buffer for
glBindBufferBase/glBindBufferRange.
Coincidentally, this is being discussed by the ARB right now.
It sounds like AMD's driver generates GL_INVALID_OPERATION if there's
no buffer object already defined when glBindBufferBase/Range() are
called. That seems to make sense since the buffer's size is used to
do error checking for glBindBufferRange() so if there's no previously
defined buffer, the error check would always fail.
But NVIDIA generates a new buffer object if one doesn't already exist.
The above-mentioned buffer offset/size check is practically
meaningless since the buffer size can change later by calling
glBufferData().
Since the spec isn't clear and other implementations vary, I'd
probably go for the more forward-looking approach and require that
buffer is previously gen'd. I'd probably leave the offset/size check
in place too, until/if the ARB says differently.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
