Skip to main content
gamedev.net
🔒 Locked

PS Speed Drop

Started by rick_appleton May 13, 2004 at 5:11 AM 14 replies 1.1k views
Original Post
rick_appleton
rick_appleton
I''ve recently implemented shaders in my engine using GLSlang. Now I''ve coded a fairly simple shader pair to emulate diffuse + specular lighting from two lights. vertex
varying vec3 posToView;
varying vec3 transformedNormal;
varying vec3 posToLight1;
varying vec3 posToLight2;

void main(void)
{
  vec3 ecPosition = vec3(gl_ModelViewMatrix * gl_Vertex);
	posToView = normalize(-ecPosition);	
  transformedNormal = normalize(gl_NormalMatrix * gl_Normal);
  posToLight1 = normalize(gl_LightSource[0].position.xyz - ecPosition);
  posToLight2 = normalize(gl_LightSource[1].position.xyz - ecPosition);
	
	gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
fragment
varying vec3 posToView;
varying vec3 transformedNormal;
varying vec3 posToLight1;
varying vec3 posToLight2;

void main (void)
{ 
  vec3 E = normalize(posToView);

  vec3 R = normalize(-reflect(posToLight1,transformedNormal));
  vec4 Idiff1 = gl_LightSource[0].diffuse * max(dot(posToLight1, transformedNormal), 0.0);
  vec4 Ispec1 = vec4(1.0, 1.0, 1.0, 1.0) * pow(max(dot(R,E),0.0), 16.0);
  R = normalize(-reflect(posToLight2,transformedNormal));
  vec4 Idiff2 = gl_LightSource[1].diffuse * max(dot(posToLight2, transformedNormal), 0.0);
  vec4 Ispec2 = vec4(1.0, 1.0, 1.0, 1.0) * pow(max(dot(R,E),0.0), 16.0);
  
  gl_FragColor = Idiff1 + Ispec1 + Idiff2 + Ispec2;
}
When I enable this shader, my fps drops from 630 to 530. When I''m not using the shaders, I let the fixed function pipeline in opengl calculate the diffuse colors only with the same two lights. Now it seems to me, there shouldn''t be such a large drop in speed. I just tested some more, with emulating the diffuse color only in the vertex shader, and not having a pixel shader. This drops the framerate to around 500 fps. Why would a vertex shader only, have a lower fps than a vertex and pixelshader both? (in this case I write to gl_FrontColor in the vertex shader)
iNsAn1tY
iNsAn1tY
Well, don''t forget that the fixed pipeline will always be faster than any equivalent code you write, as the fixed pipeline is implemented in hardware, and is highly optimized. Your vertex and fragment programs have to be executed by the GPU, and although they''re running on hardware too, programmable pipelines cannot be as highly optimized as the fixed pipeline, simply because they have to run different programs. Plus, 630fps -> 530fps is not a very big drop really. I''d be concerned if the framerate had dropped off big time, like down to 30fps, or something As for your second test, it could be that the switch from programmable vertex processing to fixed pipeline fragment processing causes a slowdown on your card, although I''m not sure how likely that is...
My opinion is a recombination and regurgitation of the opinions of those around me. I bring nothing new to the table, and as such, can be safely ignored.[ Useful things - Firefox | GLee | Boost | DevIL ]
rick_appleton
rick_appleton
Thanks for the reply. While I agree that a drop from 630 to 530 isn''t that large, I was still wondering about it.

Btw, I remember reading somewhere that one of the new videocards I think will have no more fixed function, but that it will be replaced by standard programmable shaders?
Ostsol
Ostsol
The fixed function pipeline is not always implemented in hardware. It has become increasingly common for the drivers to emulate the fixed function pipeline using shaders. This is the case will all recent ATI cards. Also keep in mind that most of what the fixed function pipeline does is on a per-vertex basis. You, however, are performing per-pixel lighting. As such, fillrate becomes an issue.
-Ostsol
rick_appleton
rick_appleton
Ostsol: I thought about that as well. The code provided above is indeed per-pixel. But like I said in my first post, I then changed it to diffuse only, per vertex, and __NO__ fragment shader. That should emulate the standard opengl behaviour exactly. That gave me an even lower fps then the per-pixel lighting. (Not much, but is was lower).
klajntib
klajntib
Try using you vertex shader (the one you use without a pixel shader) with a very simple pixel shader:

gl_FragColor = vertex-shader-calculated color

report your findings
rick_appleton
rick_appleton
Fixed Function: 630
VP 2 Diffuse Lights, No Fragment Program: 575
VP 2 Diffuse Lights, Fragment Program assignment: 590
VP, FP 2 Diffuse+specular: 590

Here are some new numbers (they do seem a bit better than in my initial post, dont know why for sure). First the fixed function 2 diffuse lights. Second diffuse color for 2 lights calculated in vertex program, no fragment program. Third a vertex program which calculates the color, then passes that to the fragment program, which simply assigns the incoming color to the output buffer. Last a vertex program which passes normals to the fragment program, and the fragment calculates per-pixel diffuse + specular color for 2 lights.

It seems that it''s a bad idea to mix a single shader with fixed function.
_the_phantom_
_the_phantom_
aye, certainly looks that way, there isnt a good reason in the spec why that would be so, so it looks to be a driver thing, so really, worse case you have to write a frag shader which assigns color and thats all.
Deyja
Deyja
Concerning yourself over such an insubstantial loss in FPS is idiotic. The higher your fps, the more a slight increase in frametime will effect it. Your shader is taking a few milliseconds more then before. Big deal.
Fingers_
Fingers_
When measuring performance impact of something like this, you shouldn''t be looking at FPS. Instead use the performance counter to just get the rendering time. The change from 630 to 530fps you quote in the first post is only 0.3ms added per frame! That will mean absolutely nothing when you have an actual game running (hopefully) around 10-15ms/frame.
_the_phantom_
_the_phantom_
that depends however, if the vertex/frag shaders are going to be used on alot of objects it could become an issue after a while so its worth while finding out the most optimal way of doing it, namely including a simple frag shader to pass teh color down instead of letting fixed function deal with it.
rick_appleton
rick_appleton
Yes, I realize that this drop is quite insignificant. I was asking more about the why of the drop then how to get rid of it. Also, I think it pays off to keep these kind of small things under wraps, else they might come and bite you later

Like _the_phantom says; right now it''s just a single object, with a simple shader. But what if more objects come, with more complicated shaders. All those 0.15 ms will add up.
_DarkWIng_
_DarkWIng_
So why not just test it in full scene, not just one object.

You should never let your fears become the boundaries of your dreams.
You should never let your fears become the boundaries of your dreams.
rick_appleton
rick_appleton
Because my engine is still under development . I can only load single objects, and have to do that in code. I''m working on a scene/level loader as we speak, so once that''s done I can easily test entire scenes.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.