performances float arrays VS float textures

[Baccanno]

Hello there,

I'm having very big performance issues with float textures.

I have a common shader calling a function called

float getGrammarParamAt( float i )

and I'm linking these two function depending on if I'm using RGBA texture or array (I also have a version for luminance only textures, size is 4 time bigger and performances are even lowest)



// grammar parameters
uniform float[300] grammarParam;


float getGrammarParamAt( float i )
{
return grammarParam[i];
}


// grammar parameters
uniform sampler2D grammarTexture;
uniform vec3 grammarTextureInformation;

float getGrammarParamAt( float i )
{
//i * 1/(length-1)
float index = i * grammarTextureInformation.x;

//cheap modulo 4
float mod4 = i * 0.25 - floor( i * 0.25 );
vec4 val = texture2D( grammarTexture , vec2( index , 0.0 ) );

if ( mod4 == 0.0 ) return val.x;
else if ( mod4 == 0.25 ) return val.y;
else if ( mod4 == 0.5 ) return val.z;
else return val.w;

}


The two codes are working properly however in first case if I have 80 fps it is going down to 6-7 with textures access. I'm making the same number of calls (the common shader does not change)

I got a GeForce 260GTX and under Fedora 14.

My guess is that it can be link to :
- Drivers ?
- Texture access is damn 10 times slower than array access ?
- The huge slow down comes from the if statements in the function ?

My texture or array is loaded only once.

Do someone had this issue before or have any clue to enhance this ?

(For the one who may ask, I want to use a texture because array is far to limited in term of size)

Thanks

[BionicBytes]

What format is your texture and how have you created the texture (glTexImage{n}d command)? What size is the texture?
Have you considered using the newer single channel colour texture formats, eg GL_R32F as this would simply be an array of floats like your unifornm array and you could then eliminate the IF ELSE branching from the shader.

[Baccanno]

Thank you for your answer. I'm actually not doing openGl directly but use a plateforme based on X3D/VRML. The texture is quite small atm, 1 * 1000 in average.

The node I'm using is called pixelTexture and I still have to be compliant with the specification.

For RGBA textures i'm using the following values :
format = GL_RGBA;
internalFormat = GL_RGBA32F;
type = GL_FLOAT;


Have you considered using the newer single channel colour texture formats, eg GL_R32F

Well I tested with a luminance texture with following parameters
format = GL_LUMINANCE;
internalFormat = GL_LUMINANCE32F_ARB;
type = GL_FLOAT;



// grammar parameters
uniform sampler2D grammarTexture;
uniform vec3 grammarTextureInformation;

float getGrammarParamAt( float i )
{
//i * 1/(length-1)
float index = i * grammarTextureInformation.x;
return texture2D( grammarTexture , vec2( index , 0.0 ) ).x;
}

And performances are as bad (may be 8-9 fps instead of 6-7, but 4 time more memory )

[BionicBytes]

What hardware do you have.
I render to GL_RED format textures and have no performance issues (GL_R32F internal format).
Some h/w may not like the luminance format, so try the GL_RED instead. Have you checked which extentensions and GL version you have (and therefore which supported floating point textures you can use)?

[Baccanno]

Told that I have a GTX260, btw texture fetch is not supported that why I must retrieve my values this way.

Concerning extension this seems to be the one ?
GL_ARB_texture_float

I'll try GL_RED and tell you the results ! Thanks

[Baccanno]

I tried with GL_RED and GL_R32F as internal, unfortunatelly framerate is still around 10 fps =(

[Alfonse Reinheart]

How many times are you calling this "getGrammarParamAt" function within a single shader execution?

Also, why is it that the uniform array case just pulls a value from the uniform array, while the texture case has to go through a bunch of number crunching for the index, as well as a giant switch statement at the bottom to decide which of the four values pulled from the texture to return? That doesn't really make sense. If you're using a LUMINANCE texture, then the first 3 values are the same. And if you're using an RGBA texture... why would you be using an RGBA texture for what is obviously single-channel data?

Lastly, uniform arrays will always be faster than texture accesses.

[Baccanno]

How many times are you calling this "getGrammarParamAt" function within a single shader execution?
The shader actually does a tree exploration so depending on the pixel and tree height/depth can vary from 10 to 40 times. I know this is big.


why would you be using an RGBA texture for what is obviously single-channel data?
The main purpose was to save storage place.
Now if you say to me that a luminance texture is coded on one byte only, then of course no need of RGBA.


Lastly, uniform arrays will always be faster than texture accesses
I guess there is no other possibility than diminishing the number of call to the texture access.
Still I didn't know that the access was that slow. Maybe because of float values