View Full Version : Array size limits

10-09-2007, 11:14 PM
While thinking of some optimizations that I can make on my fragment program, I began to wonder how expensive texture2D() sampler calls are. I have to make 4 sampler calls (with GL_NEAREST) per fragment.

What if I could read and write the data in a huge array and access that instead of textures?

The question is: Would GLSL allow me to declare arrays of incredibly large size? The GLSL Language Spec doesn't mention a limit.

Would it be one of those "driver dependant" limitations?

10-10-2007, 01:05 AM
Use textures :)

10-10-2007, 05:19 AM
If you use uniforms, then that uses up "constant registers" which is a kind of memory on the GPU and the GPU may have 256 or 512 or who knows what.

Do what he said.

10-10-2007, 06:03 AM
There is also this new extension, EXT_texture_buffer_object. It allows to create huge (2^27) one dimensional textures directly from buffer objects.

10-10-2007, 08:02 AM
I am not sure that the arrays would need to be uniforms. My application code has no need to read or write to the array. Though I would need one vert+frag program set to write to the array while a second set of vert+frag programs read from it... I don't know if that is possible.

I guess I am just wishing for something that has a better fit for full screen deferred rendering.

As it is now, I have to write to several different textures in order to store all the data I need. Which means multiple parses of the scene's geometry during writing and multiple non-interpolated sampler calls (to the same coordinates) during reading.

It just seems like a different system would fit better... Maybe a future OpenGL development could be: Textures with an arbitrary number of data channels per pixel.

10-10-2007, 08:45 AM
What about multiple render targets (MRT)?

10-10-2007, 08:52 AM
Really? I hadn't heard of that. Thanks, I will look into it.