buffer_storage

[Alfonse Reinheart]

I think the GL_AMD_pinned_memory extension is a nice approach for uploading use-once data.

But that's not what the extension does. It doesn't upload anything. It's purpose is to allow client memory to be used more or less like a buffer object. It's real purpose is to get around the fact that glTexImage* functions have to be finished with client memory when they return.

I wouldn't be adverse to a glBufferClient function, which like glBufferStorage would create an immutable buffer object with certain properties. But to be honest, I'd much rather have a special set of glTexSubImage* calls or something else than to overload buffer object functionality for this purpose.

[mbentrup]

Well, afaik AMD hasn't published the extension spec yet, so it's all a bit of speculation, but though their presentation showed the extension on PBOs, there was nothing that indicates that is wouldn't work the same way for any other type of BO.

[elFarto]

Ok, but I'm not sure how replacing one method that has a hint the driver (mostly) ignores, with another method that has a hint the driver could possibly ignore, improves things.

Also, do you have any more information on the difference between 'invalidating memory' and 'reallocating it'. Reading through Rob's suggestion, it seems invalidating the buffer means the driver will orphan the currently allocated memory and allocate another slab. I can't see how changing the size between calls is going to impact that.

*edit* Is glFlushMappedBufferRange meant to return a GLsync object..?

Regards
elFarto

[Alfonse Reinheart]

Ok, but I'm not sure how replacing one method that has a hint the driver (mostly) ignores, with another method that has a hint the driver could possibly ignore, improves things.

The driver could ignore it, in the sense that it could choose not to do something more optimal in the restricted cases. But the primary difference is simple.

AMD's drivers ignore the hints, but they do not ignore usage patterns. Essentially, they pick optimal memory layouts and allocations based on how you actually use the buffer, not on how you say you're going to. If the API forces you to use the buffer a certain way, then it's really no different from AMD's perspective. There's just a nice API there to guarantee that you don't go back on your word. They don't have to look at what that word is when picking out where your memory goes.

Also, there's the fact that the API is self-documenting. You use the most restrictive form of buffer object that you can live with. You don't have to guess at what magical access pattern driver developers will be optimizing for, since the access patterns are enforced by the API.

I can't see how changing the size between calls is going to impact that.

It all depends on how it gets implemented. If a driver sees you doing lots of buffer invalidation, then it can basically allocate two pieces of memory the same size as the requested buffer and just swap back and forth between them. Or if you do a lot of invalidations, 3 pieces of memory. Or whatever.

It's all about giving implementations more information up-front about how you're going to use the buffer, and then forcing the user to live within those restrictions.

[kRogue]

My only thoughts on this are that we already have a fair number of buffer object hints (in creation and binding) that are completely implementation defined in their effects, as Dark Photon[I think] once called it the "buffer object Ouija board", adding more flags, enumeration and such although in theory could help, I would suspect it might just make that Ouija board bigger.

[Alfonse Reinheart]

The point is that they're not hints. A hint is not something you have to abide by. That's why they fail (besides being poorly specified): because you can set them to one thing and then do something else.

If you use the "write exactly once" behavior, you get exactly one chance to write to the buffer; all subsequent attempts will fail with a GL_INVALID_OPERATION error. The point of behaviors is that they would be enforced.

The only guesswork you might have to do is which behavior to use in which implementations. And even then, the behaviors are designed to be functional subsets of one another. So it would take a pretty poorly written implementation to make "write anytime" faster than "write once then invalidate". They could be the same speed, but there's no reason for the more restricted one to be slower.

And even in the unlikely event that each behavior had completely unknown performance characteristics on implementations relative to one another, the access patterns are well specified. And finite. Therefore, the only possible "Ouija board" issue would be if "write anytime" allowed access patterns not specified by behaviors that were somehow faster than one of the more restrictive ones. And that seems very unlikely; the list of behaviors is always open to debate if someone has an access pattern that would legitimately be faster.

[l_belev]

as arekkusu said, textures have great problem because of the mipmaps.

imagine this situation:
the app creates a new texture,
then it specifies all even mips with some internal format (e.g. rgba8)
then it specifies all odd mips with different internal format (e.g. rgb5)

at this point the texture is incomplete but if the app does one of these 2 things: re-specify the odd mips with rgba8 or re-specify the even mips with rgb5, then the texture should become complete.

of course this would be quite idiotic behaviour by the app, but still it is completely valid and permitted by the api spec and so the implementation should handle it correctly.

thus the implementation should always save any image in any format you specify for any mip, even if there are no 2 mips with the same format.

imagine what nightmare is this for the implementation.

also these saved images should be placed in system memory - no point of uploading them to the video memory for at this point the texture is unusable anyway and we dont know what will be the final format when/if it eventually becomes complete.
so each texture must also have a backing system memory copy at least until it becomes complete, which can be avoided with the new immutable property.

this is the main reason for the new immutable texture thing.
the buffers don't have mips and this bad problem does not exist for them.

[Alfonse Reinheart]

the buffers don't have mips and this bad problem does not exist for them.

I know. But buffers have other problems, which I addressed. I don't see how what you're talking about is relevant.

[l_belev]

you say the main problem this would solve is to avoid using BufferData just for invalidation because the user may mess up the params.
i am very much against api designs that try to prevent the programmer from making mistakes, so for me this reason is invalid. but i wont go into a debate about it.

another problem you mention are the usage hints. i agree here, mandatory (not hint-only) usage flags would be good to have.
but i dont see what this has to do with immutability - why a buffer has to be immutable in order to have mandatory usage flags?

[Alfonse Reinheart]

i am very much against api designs that try to prevent the programmer from making mistakes, so for me this reason is invalid.

OK, let's play this game.

Why does glTexStorage make the texture immutable? Preventing the programmer from making mistakes is the pretty much the entire point of making glTexStorage textures immutable.

After all:

imagine this situation:
the app creates a new texture,
then it specifies all even mips with some internal format (e.g. rgba8)
then it specifies all odd mips with different internal format (e.g. rgb5)

That is a mistake. That creates a texture which cannot be used. It is an incomplete texture. But the driver still has to accept it; just because the texture is incomplete now doesn't mean that it won't be complete in the future. The driver is required to live with this half-state.

Aside from making the texture immutable, glTexStorage does nothing that you could not do before in your own code. You could create all of your textures by calling glTexImage* on them in a loop, using NULL as the data, then upload with glTexSubImage* as needed. You could set the GL_TEXTURE_BASE/MAX_LEVEL parameters correctly, and thus ensure that your textures are mipmap complete. You could use sized internal formats instead of unsized ones. And you could make them "immutable" by never touching any of this stuff again.

So why does this extension exist, if it does not allow you to do anything that you couldn't before? What is it about glTexStorage that opens up optimization potential?

Consider this except from the the issues section of ARB_texture_storage:

4. Should use of these entry-points make the metadata (format and dimensions) immutable?

RESOLVED: Yes.

DISCUSSION: The benefits of knowing metadata can't change will probably outweigh the extra cost of checking the TEXTURE_IMMUTABLE_FORMAT flag on each texture specification call.

5. Should it be legal to completely replace the texture using a new call to TexStorage*?

RESOLVED. It will not be allowed.

DISCUSSION: This is useful to invalidate all levels of a texture. Allowing the metadata to be changed here seems easier than trying to define a portable definition of what it means to change the metadata (e.g. what if you used an unsized internal format the first time and the corresponding sized internal format the second time, or vice versa)?

However, while this is largely similar to deleting the old texture object and replacing it with a new one, it does lose some of the advantages of immutability. Specifically, because doing so does not reset bindings, it doesn't allow a migration path to an API that validates the texture format at bind time.

Immutability is valued by the ARB. By the driver developers. Why?

Because an API that allows the programmer to make mistakes also is an API that requires that the implementation accept those mistakes. It has to deal with it. It has to handle erroneous badness with a smile.

"api designs that try to prevent the programmer from making mistakes" are also API designs that make it easier for implementers to optimize. Because the user cannot put the system in an invalid state, there is no question about what the valid states are. And therefore, the driver doesn't have to worry about those cases where weirdness is happening. Everything is simple, regular, and expected. And once the driver developer knows how the user is going to go about their business, they can get to their business of making things fast.

I see no reason why that logic should not apply to buffer objects too. The ability to call glBufferData on an object multiple times with different sizes and hints, all without changing the object name, goes against the last part of the ARB_texture_storage quote. The part about the eventual migration to bind-time validation.

Making buffer objects immutable, but allowing for invalidation via a specialized function call, means that you can retain bind-time validation, since you know the size of it even after it is invalidated. A glBindBufferRange that was in-range before validation remains in-range after. While the GPU pointers may have changed, the range didn't.

Yes, it prevents mistakes, but it was allowing those mistakes to begin with that is a big reason for the "buffer object Ouija board", as Dark Photon would say. Preventing mistakes is good for everyone.

but i dont see what this has to do with immutability - why a buffer has to be immutable in order to have mandatory usage flags?

Because it makes it impossible to change the usage flags later. If you can only call glBufferStorage one time, then the implementation knows that this object name will be forever associated with a block of memory of known size and will always have a particular usage pattern. The driver doesn't have to be written to deal with changing this usage pattern in the future.

Again, the same argument for glTexStorage's immutability.