If you’re going to store uniforms in a buffer object, then this is how you have to do it.
What you say makes sense. I don’t really like the idea to expose memory layout details to the application.
But I don’t think these “buffer objects” are meant to have transparent layout.
New Uses for Buffer Objects have been defined to allow the application to use buffer objects to store shader uniforms, textures, and the output from vertex and geometry shaders.
Note that they speak of a single object type called “Buffer Object”, that can be used for all these things. I assume this is the same buffer object as in VBO/PBO. I don’t see how transparent layout would fit into this, especially when using multi-purpose buffer objects (e.g. use transform feedback data as uniforms).
Maybe we’ll just get two seperate uniform setting methods, one based on buffer objects and one with transparent layout
Let me try to summarize how this works. Again, all tentative and subject to change.
Create a program object
Create buffer object(s) of appropriate size for the uniform partition(s).
Query the uniform offsets from the program object. This is a byte offset within the corresponding buffer object.
Load values into the appropriate locations within the buffer object(s). You can use any available technique for populating buffer objects, e.g. BufferData, MapBuffer, PBO reads, etc.
Image and texture Filter objects are attached directly to the program object, as are the buffer objects. When you bind a program, it pulls in all dependent objects in a single call.
How do you get to use the same buffer object for multiple programs, if they could be using different sets of uniform partitions for the same uniform data?
You need to use several uniform-blocks, that are equal in all the shaders, where you want to use them.
Example:
shader1
uniform block A
{
float
float
int
}
uniform block B
{
float
int
}
shader2
uniform block C
{
int
float
vector
}
uniform block D
{
float
int
}
Now block B and D have an equal layout, therefore you can bind one buffer to both B and D. If shaders need different data, you put general data into one block (B and D) and the data that is shader-specific is put into a different block (A and C).
You need to do the same thing for data that is updated at a different frequency, as mentioned above somewhere, if you want to prevent needless uploading of data.
Ok, then my basic understanding about everything that has nothing to do with samplers was correct, too. That brings me back to my original question
I still don’t understand how textures fit into this. Ok, the image and filter objects are bound directly to the program object. But how are they connected to the sampler uniforms? Do I have to bind it to an uniform id (something like glBindObjecti_o(program, uniformID, image)?
Also, when binding textures to programs, how can I change all textures with a single call? I was hoping that in Long Peaks we would be able to change all material parameters (that is, uniforms and textures) with a single call.
Do I have to bind it to an uniform id (something like glBindObjecti_o(program, uniformID, image)?
Yes.
Also, when binding textures to programs, how can I change all textures with a single call? I was hoping that in Long Peaks we would be able to change all material parameters (that is, uniforms and textures) with a single call.
That’s a very good point.
More than likely, you’re going to be using the same program with many image/sampler pairs.
It would be better to be able to take a program and create a “sampler block” object that you bind image/sampler pairs to. It, combined with uniform buffers, would work much like having an instance of a program. Thus you can render simply by binding program, the uniform buffers, and sampler block to the context and then rendering.
The ultimate hope is to be able to fully instance programs. That is, have the program itself not really own any state, but have it associated with these other objects that apply their state to the program.
I’m very interrested in the new object model proposed, anyone knows when drivers supporting this will be out?
I’m guessing not before there’s a published spec. Which won’t happen until summer at the earliest.
