Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411640 Posts in 69394 Topics- by 58449 Members - Latest Member: pp_mech

May 14, 2024, 10:05:00 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Updating uniform variables per frame
Pages: [1]
Print
Author Topic: Updating uniform variables per frame  (Read 1431 times)
Sigma
Level 1
*


View Profile WWW
« on: August 31, 2014, 08:30:50 PM »

Hi all,
 Is it the right thing to update uniform variables in a pixel shader every frame ? if not what's the best approach to update variable in a pixel shader every frame. I'm seeing poor fps after i changed my code to update uniform variables every frame. Also the updating variables are an object of a struct.

All helps are highly appreciated
Logged

epcc
Level 1
*


View Profile
« Reply #1 on: September 01, 2014, 05:11:43 AM »

Setting uniform variables isn't very expensive, they can be updated every frame or even multiple times per frame without much of a performance hit.
Try profiling your code to see what slows it down.

Logged

Boreal
Level 6
*


Reinventing the wheel


View Profile
« Reply #2 on: September 01, 2014, 07:40:47 AM »

Best would be to use a buffer-backed uniform block and update with GL_DYNAMIC_DRAW and glBufferSubData().
Logged

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
Sigma
Level 1
*


View Profile WWW
« Reply #3 on: September 01, 2014, 09:19:54 PM »

Best would be to use a buffer-backed uniform block and update with GL_DYNAMIC_DRAW and glBufferSubData().

i have no idea how to achieve this using cocos2dx and i'm new to openglES as well, better u can help me understand.

Setting uniform variables isn't very expensive, they can be updated every frame or even multiple times per frame without much of a performance hit.
Try profiling your code to see what slows it down.
actually i'm running a pixel shader on a full screen size image (960x640), i have distance calculation as well that eats up most of the fps. i could see this by commenting out the distance calculation

without shader FPS - 60
With shader FPS - 15

i have pasted my code here plz have a look and let me know whats wrong in this code

Code:
#ifdef GL_ES
precision mediump float;
#endif

struct Light
{
  vec3 position;
  vec3 color;
  float intensity;
  int active;
};

uniform Light lights[5];

varying mediump vec2 v_texCoord;
uniform float u_lightInnerFallOff;
uniform vec2 u_resolution;
uniform float u_fragAlpha;

void main()
{
    vec4 fragColor = texture2D(CC_Texture0, v_texCoord);
    vec3 v_fragmentIntensity = fragColor.rgb;
    float fragAlpha = u_fragAlpha;
    for (int index = 0; index < 5; index++)
    {
        if (lights[index].active == 1)
{
    mediump float lightDist = distance(vec3((v_texCoord * u_resolution), 0.0), lights[index].position);
   
    lowp float lightValue;

    if (lightDist < u_lightInnerFallOff)
    {
lightValue = 1.0;
v_fragmentIntensity = lights[index].color * vec3(1.0, 1.0, 1.0);
    }
    else
    {
lightValue = u_lightInnerFallOff/lightDist;
v_fragmentIntensity = lights[index].color * v_fragmentIntensity;
    }
    fragAlpha = fragAlpha + (lightValue * lights[index].intensity);
}
   }
    gl_FragColor = vec4(v_fragmentIntensity, fragAlpha);
}

Things i have tried so far
    1. changed the precision to lowp - no performance boost
    2. commented out the v_Coord manipulation as per apple dev doc - no performance boost
    3. after commenting distance calculation in shader FPS increased to 30;
   
still something is eating up 30 fps, dont know where, all helps are highly appreciated.


Thanks
 
Logged

rosholger
Level 1
*



View Profile
« Reply #4 on: September 02, 2014, 04:13:53 AM »

your problem is probably all of that branching, branching in shaders kill performance sadly
Logged
Sigma
Level 1
*


View Profile WWW
« Reply #5 on: September 02, 2014, 05:47:25 AM »

your problem is probably all of that branching, branching in shaders kill performance sadly
You saved my life, i never knew that. Thanks a lot... Just removing the for loop and if-else statement shoots up the fps to 30 from 12. Is there any other things i can improve in this code.
Logged

rosholger
Level 1
*



View Profile
« Reply #6 on: September 02, 2014, 09:20:28 AM »

your problem is probably all of that branching, branching in shaders kill performance sadly
You saved my life, i never knew that. Thanks a lot... Just removing the for loop and if-else statement shoots up the fps to 30 from 12. Is there any other things i can improve in this code.
Your welcome! don't know of anything else, im actually pretty bad at shaders  Shrug
Logged
Sigma
Level 1
*


View Profile WWW
« Reply #7 on: September 02, 2014, 09:31:50 AM »

your problem is probably all of that branching, branching in shaders kill performance sadly
You saved my life, i never knew that. Thanks a lot... Just removing the for loop and if-else statement shoots up the fps to 30 from 12. Is there any other things i can improve in this code.
Your welcome! don't know of anything else, im actually pretty bad at shaders  Shrug
anyway thank u Smiley
Logged

Sigma
Level 1
*


View Profile WWW
« Reply #8 on: September 04, 2014, 02:52:30 AM »

only in older GeForce GPU its slow, in Adreno GPU's its more than 60FPS always Smiley
Logged

manabreak
Level 0
***


dManabreak @ Twitter


View Profile
« Reply #9 on: September 05, 2014, 03:57:38 AM »

Like already said, branching is bad. And so are loops. If you need loops but get a performance bump, one thing to do is to unroll the loops.

Code:
// Loop
for(int i = 0; i < 5; ++i) {
    nippleColors[i] = calculateNippleColor(i);
}

// Loop unrolled
nippleColors[0] = calculateNippleColor(0);
nippleColors[1] = calculateNippleColor(1);
nippleColors[2] = calculateNippleColor(2);
nippleColors[3] = calculateNippleColor(3);
nippleColors[4] = calculateNippleColor(4);

This speeds the code up a bit because it doesn't have to do the conditional check (i < 5) every time the loop is finished. Of course, it increases the binary size of the shader program, but that isn't usually a big problem - the size doesn't get dramatically larger in such simple cases. Smiley
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #10 on: September 05, 2014, 10:39:17 AM »

Most drivers will be happy to unroll that loop for you.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic