Performances float arrays VS float textures

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

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.

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 )

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)?

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

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

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.

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

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.