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

''"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?

+

talking about glGen* in general - which one is right now? [[User:Gruppjo|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 {{code|glBufferData}}. There is no {{code|glCopyTexImage}} equivalent that can act as an alternative to {{code|glTexImage}}.

: 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 {{code|glBufferData}}. There is no {{code|glCopyTexImage}} equivalent that can act as an alternative to {{code|glTexImage}}.

Line 86:

Line 86:

:: 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?

:: 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?

+

+

:: The speciality of buffer objects is that you can't really use them without further assigning its data with glBufferData, right? [[User:Gruppjo|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 {{code|glTexImage}} or similar functions. You can't use an FBO for something useful until you attach some images to it. And so on.

Latest revision as of 05:05, 23 January 2012

Contents

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)

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.

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"

"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.