Talk:Buffer Object

From OpenGL.org
(Redirected from Talk:Buffer Objects)
Jump to: navigation, search

Using vertex arrays without buffer objects in GL 3.1+

"OpenGL 3.1 and above no longer allow the use of vertex arrays without buffer objects."

Is this right ? I am currently using a 3.2 forward compatible context and vertex arrays inside without problems... I am using the last NVIDIA drivers for Linux (195.17)

EDIT: Ok, checked the spec, this must be a driver bug, as the spec says:

"An INVALID_OPERATION error is generated if any of the *Pointer commands specifying the location and organization of vertex array data are called while zero is bound to the ARRAY_BUFFER buffer object binding point (see section 2.9.6), and the pointer argument is not NULL."

Unbinding mapped buffers

"While a buffer is mapped, you cannot do anything to it. Do not call any OpenGL function that would cause OpenGL to write to or read from that buffer. Doing so can have unfortunate consequences. Most important of all, do not unbind the buffer while it is mapped. It's OK to do these things before you map the buffer, but not while it is mapped."

I'm not sure that's totally accurate, as it implies that only one buffer can be mapped at a time. The final example given in the vertex_buffer_object spec [1] demonstrates that multiple buffers can be mapped through a bind/map/bind/map sequence of calls, effectively unbinding the first buffer while leaving it mapped. If unbinding a mapped buffer was unsafe, the spec wouldn't have such an example. --JThoenen 03:51, 29 September 2009 (UTC)

Fixed. Alfonse 22:48, 29 September 2009 (UTC)

Buffer Object Usage

"STREAM is pretty easy to understand: the buffer object's contents will be updated after almost every use. [...] What is unclear is when DYNAMIC becomes STREAM or STATIC."

This does not agree with the 2.1 specification:

"STREAM
The data store contents will be modified once and used at most a few times."

According to the latter, STREAM usage is designed for some sort of streamed data which is downloaded, used, and disposed of right away. There is no confusion between the three usage modes: STREAM is for one-off buffers, STATIC is for immutable, and DYNAMIC is for constantly changing data.

"They (hints) are all based on what the user will be doing with the buffer. That is, whether the user will be directly reading or writing the buffer's data."

This does not follow from the specs:

"usage can be broken down into two parts: first, the frequency of access (modification and usage), and second, the nature of that access."

From this I would conclude that a transform feedback buffer should be DYNAMIC_COPY for instance.

SnakE 19:09, 19 May 2010 (UTC)

Update

Here's an excerpt from the 4.0 specification which describes the hints meaning very clearly:

usage is specified as one of nine enumerated values, indicating the expected application usage pattern of the data store. The values are:
STREAM_DRAW
The data store contents will be specified once by the application, and used at most a few times as the source for GL drawing and image specification commands.
STREAM_READ
The data store contents will be specified once by reading data from the GL, and queried at most a few times by the application.
STREAM_COPY
The data store contents will be specified once by reading data from the GL, and used at most a few times as the source for GL drawing and image specification commands.
STATIC_DRAW
The data store contents will be specified once by the application, and used many times as the source for GL drawing and image specification commands.
STATIC_READ
The data store contents will be specified once by reading data from the GL, and queried many times by the application.
STATIC_COPY
The data store contents will be specified once by reading data from the GL, and used many times as the source for GL drawing and image specification commands.
DYNAMIC_DRAW
The data store contents will be specified repeatedly by the application, and used many times as the source for GL drawing and image specification commands.
DYNAMIC_READ
The data store contents will be specified repeatedly by reading data from the GL, and queried many times by the application.
DYNAMIC_COPY
The data store contents will be specified repeatedly by reading data from the GL, and used many times as the source for GL drawing and image specification commands.

SnakE 13:22, 20 May 2010 (UTC)

And yet, if you look at how, for example NVIDIA, suggests that buffer hints be used, it is very clear that what this is referring to is the ratio between calling glBufferData (or glMapBufferRange with invalidate) and how often it gets used. 1:N is STATIc, N:N is STREAM, and somewhere in the middle is DYNAMIC. Just the name "stream" suggests what it is for: a buffer that you will be constantly changing the value of. This is as opposed to a buffer you will change the data of occassionally, but not every frame.
The per-frame guarantee is very useful when allocating memory. If an implementation gets a STREAM, then it could allocate 2x the size of memory requested, and then every time the buffer is respecified/invalidated, it just swaps pointers. Alfonse 04:20, 21 May 2010 (UTC)
I removed a few of your lines; they made it difficult to follow the thread of discussion. Alfonse 04:21, 21 May 2010 (UTC)

Creation

"As with the standard OpenGL object paradigm, this only creates the object's name"

Is that right, talking about using glGenBuffers?

Because on the wiki: OpenGL_Objects#Object_Creation_and_Destruction it says:

"To create an object, you generate the object's name. This creates an empty object of the given type."

talking about glGen* in general - which one is right now? Gruppjo 02:05, 13 January 2012 (PST)

They're both right, because they're both saying the same thing, more or less. The primary difference is this. When you create a sampler object name, it gets the state it needs when you first bind it. When you create a texture object name, it gets the state it needs when you first bind it. And while this is technically true of buffer objects, you can't really do anything with a buffer object without first calling glBufferData​. There is no glCopyTexImage​ equivalent that can act as an alternative to glTexImage​.
So really, it is the wording on the OpenGL Objects page that needs tweaking. And I have since done so. Alfonse 01:04, 14 January 2012 (PST)
Thanks for settings this right. So upon calling glGen* you create the object name and the object itself, but it is empty. Then, when binding the object it will get its state. - That's true for all objects, right?
The speciality of buffer objects is that you can't really use them without further assigning its data with glBufferData, right? Gruppjo 02:05, 15 January 2012 (PST)
That's true of most objects. You can't use a texture object for anything useful until you actually allocate memory with glTexImage​ or similar functions. You can't use an FBO for something useful until you attach some images to it. And so on.
Also, sign your posts on talk pages. Alfonse 07:52, 18 January 2012 (PST)