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.
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.