FShader gives different output on different phones

OpenGL
1

I am trying to implement a blur filter with opengl es 2.0 on android.
Here is the code i am using.


varying highp vec2 fragTexCoord;
highp vec2 u_Scale;
uniform sampler2D s_texture;
highp vec2 gaussFilter[7];
uniform highp float radius;

highp vec4 boxVerBlur(){
	gaussFilter[0] = vec2( -3.0,0.015625);
	gaussFilter[1] = vec2(-2.0,	0.09375);
	gaussFilter[2] = vec2(-1.0,	0.234375);
	gaussFilter[3] = vec2(0.0,	0.3125);
	gaussFilter[4] = vec2(1.0,	0.234375);
	gaussFilter[5] = vec2(2.0,	0.09375);
	gaussFilter[6] = vec2(3.0,	0.015625);
	
    highp	vec4  color = vec4(0,0,0,1);
    u_Scale = vec2( 1.0/radius, 0 );
    for( int i = 0; i < 7; i++ )
    {
    	color += texture2D( s_texture, vec2( fragTexCoord.x + gaussFilter[i].x*u_Scale.x, fragTexCoord.y + gaussFilter[i].x*u_Scale.y )) * gaussFilter[i].y;
    }
    return color;
}

void main(void)
{
	gl_FragColor = boxVerBlur();
}

On “Samsung Galaxy S” it works as expected. However when i run same app on “Samsung Galaxy Ace,” it results a brighter texture without blur effect.

Result from Galaxy S

Result from Galaxy Ace

2

If i need to paraphrase the question, which part of the code above is hardware dependent ?

3

Nice look.
Out of the blue this is hard to say, you should try to remove parts of your shader to verify what specific part is done differently on both platforms.

4

What happens is you get rid of everything but just keep the basic texture access:

texture2D( s_texture, fragTexCoord);

Do you still get the washed out effect?

5

It could be due to the fact that you’re assigning the fragment an alpha of 1, and then potentially adding another 1 to that through the application of your kernel. You’d likely only notice this if blending was enabled and the color was multiplied by alpha, which could be the difference between the two cases. Try color = vec4(0) instead.

Otherwise, the incorrect result looks very much like values are being blown out greater than white. This is usually an artifact of the convolution kernel summing to a value greater than 1, even though your kernel appears to be okay in this regard. You might want to expand the loop and see if the compiler is having some issues with it.

6

No, when i just keep basic texture access i get the normal result from both of them.

7

Try precomputing 1/radius on the CPU and pass it to the fragment shader as a uniform.

8

Then by definition the only thing which is different it how you access each sample

fragTexCoord.x + gaussFilter[i].x*u_Scale.x

Perhaps unroll the loop manually and replace gaussFilter array with constant offset, eg

fragTexCoord.x + (0.3 * u_Scale.x)

9

Thank you very much, your suggestion solved my problem. I still don’t understand why though!

Also thanks to everyone for your answers.

10

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