this would be a buffer that holds uniforms.
it can be accessed from the vertex shader or pixel shader. its advantage would be not being limited to the actual number of native uniforms on the GPU. of course this would require the GPU to be able to access such buffer. This means that for this buffer to work, the actual HW must support it. so maybe in next gen HW or so we can have something like that.
Would work, and i do think that it actuarly could work on todays harware.
The ARB are working on the “super buffers” thingy and it’s not that unthinkable that this is/can be a part of it.
so what is the latest on the super buffers?
eversince the ARB had decided to stop giving out any information, we have become like pilots flying in the dark with no instrumentations 
You could use a floating point texture that holds your uniforms but you need SM3 level hw to sample them in a VS. (Geforce 6600, 6800, 7800)
Super buffers doesn’t change anything. It’s a more complex form of memory management and it gave the GL programmer more flexibility.
You can’t just create an extension and turn a non capable hw into something it isn’t.
I thought of that but you would have too many latencies that would degrade performance.
vertex shaders don’t mask texture fetch latencies as fragment shaders, and also, there is the texture creation delay, and then on top of that, you have to rescale everything twice, once on your texture writes and then on your reads since textures will store floats in the range of 0 to 1, unless, I am mistaken.
does a floating point texture store floats outside the range 0 to 1?
If you want the minimum latency, then it would have to be more uniforms which are probably registers.
What eactly is your idea of uniform buffer and how do your propose GL should be changed to support it?
Floating point textures can contain any number. They are not normalized.
A uniform buffer would work exactly like any VBO would, it would pass data directly to a uniform as you normaly would with a standard uniform (only on a per vertex basis).
If you would do that the regular (with uniforms) way you would more or less negate the whole puropse of VBOs.
If you use texturelookup you would
- waste a texture read, more if you need anything more than a float.
- waste texture memory.
- use one or more textures to many that could be used in a shader.
What would be needed in the API, a few new tokens like GL_UNIFORM_ARRAY and add glUniformPointer(GLint uniform, GLint size, GLenum type, GLsizei stride, const GLvoid *pointer);(works similar to glVertexPointer).
i believe textures are pretty much universally frowned upon for constant storage, but they are very tempting 
The d3d10 solution to this is through the use of constant/texture buffers, which allow for up to 16, 4096 4-vector buffers, per shader. You can group constants by frequency of use, to minimize bandwidth usage. Perhaps something similar could/will be exposed in GLSL?
I agree with leghorn.
Originally posted by Leghorn:
[b] i believe textures are pretty much universally frowned upon for constant storage, but they are very tempting
The d3d10 solution to this is through the use of constant/texture buffers, which allow for up to 16, 4096 4-vector buffers, per shader. You can group constants by frequency of use, to minimize bandwidth usage. Perhaps something similar could/will be exposed in GLSL? [/b]
That’s what I said. Either you use constants or store in a texture. If you have a float RGBA 2D texture, 4096 x 4096, that means a lot of space for constants.
For good cache performance, you would have to keep the texture small. It’s a trade off.
Perhaps having a API to tell the card to always keep it in cache is not a bad idea. I’m guessing that’s the idea of D3D10
Who is frowning on the use of textures?