[Mesa-dev] GL_ARB_ubo spec question

Eric Anholt eric at anholt.net
Wed Jun 27 11:01:10 PDT 2012


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120627/63dad487/attachment.pgp>


More information about the mesa-dev mailing list