working on Vertex Shader VS fixed pipeline thesis

Started by
13 comments, last by khaleelali 18 years, 3 months ago
hi, I am looking for some ideas for my thesis. I was interested in learning shaders and showing its benefits and need some help since i am new to shader. I have found that shaders can be used to do per pixel phong lighting but is there anything else where i can use a shader and get performance increase. I have implemented some code and haven't found what i need yet. Hardware is X800PRO, using OpenGl and shader are being written in GLSL Here is what i have so far. First of all I found frame rates using ATITooltrays. i saw in some examples someone using a timer.h class that calculates the frame rate and when programs, atitool tray was slow by 10 frame. i will have to check if that is true for fixed pipeline or not.(Thought i would get advise first then go about doing the coding) I have a cube that i drew using glVertex3f and each side has different colors, which were set using glcolor3f. When i run the project with only 1 cube and tell the project to rotate the cube i get 1028 in full screen. Monitor is set at 1280x1024 resolution, 32bit and Vsync if off. 1 cube gives me 1030 and 100 cubes gives me 964 frames. With this shader attached void main(void) { gl_FrontColor = gl_Color; gl_Position = ftransform(); } gets me 1024 for 1 cube and 955 frame for 100 cubes. it's off by couple of frames but my thesis is to show that shaders are faster than fixed pipeline. if i attach a frag shader that is just void main(void) { gl_FragColor = gl_Color; } i take another 8-10 frames hit. i didn't change any of the openGL code, so the glcolor3f is in both shader and non shader code. Everytime a new cube is drawn it's front face has a different color thanthe previous one drawn.(it was a project for opengl to rotate cubes and get them to match colors on all sides) i can rotate cubes in x, y or in both direction. Doesn't affect the framerates I just need advise in which direction i should go. I haven't done much advance programming with shaders yet but i have to also keep in mind the time available(was hoping for multiple examples in my thesis and 1 advance one)
Advertisement
Second i worked on introducing lights into the project. So now glcolor don't matter. One on front and one on back of cubes
Code is here

GLfloat position0[] = {0.0, 0.0, 15.0, 1.0};
GLfloat diffuse0[] = {1.0, 0.0, 0.0, 1.0};
GLfloat specular0[] = {1.0, 1.0, 1.0, 1.0};
GLfloat ambient0[] = {0.0, 1.0, 0.0, 1.0};

GLfloat position1[] = {0.0, 0.0, -15.0, 1.0};
GLfloat diffuse1[] = {0.0, 0.0, 1.0, 1.0};
GLfloat specular1[] = {0.0, 0.0, 1.0, 1.0};
GLfloat ambient1[] = {0.0, 0.0, 1.0, 1.0};

glEnable(GL_NORMALIZE);
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glLightfv(GL_LIGHT0,GL_POSITION,position0);
glLightfv(GL_LIGHT0,GL_DIFFUSE,diffuse0);
glLightfv(GL_LIGHT0,GL_SPECULAR,specular0);
glLightfv(GL_LIGHT0,GL_AMBIENT,ambient0);

glEnable(GL_LIGHTING);
glEnable(GL_LIGHT1);

glLightfv(GL_LIGHT1,GL_POSITION,position1);
glLightfv(GL_LIGHT1,GL_DIFFUSE,diffuse1);
glLightfv(GL_LIGHT1,GL_SPECULAR,specular1);
glLightfv(GL_LIGHT1,GL_AMBIENT,ambient1);

I know that i have to take care all lighting calculations in my lightshader. but without the calculations the shader is about 200 frames faster than regular code. i read that i can have regular processor do some calculations and pass it to the shader. But i don't want to code all this and end by with a shader that has no performance gain(or something that i can show is better than before) than the fixed pipeline. I am using the OpenGl Shading Language by Randi J Rost as my resource on the lighting part.
So i am asking for advice. Is this example worth the trouble or should i find something else with textures?
BTW thank you for any help i really appreciate it.
Khaleel Ali
Shaders can be more efficient if they reduce the number of passes required to render the scene.
In case of a pure FF vs. Shader I don't see how a shader could possibly be faster, especially since modern GPUs tend to translate FF calls to shader programs internally.
I'd rather focus on reducing passes and simply do things you cannot achieve with the FF pipeline efficiently - like post-processing effects, HDR rendering, many (point-) lights and such.
Also note that a framedrop by an amount of 8 to 10 in relation to a (artificial) frame rate >1000 is less than 1% in relative performance change (e.g. negligible).

HTH,
Pat.

PS: OGL Gurus - feel free to correct/enlighten me [smile]

As mentioned, I doubt shaders will win doing the identical task as the FF pipeline, however they can allow you to do the same tasks in a more "clever" way, hopefully reducing overhead.

The 3D Labs shader gen program would be a good start if your trying to start out implementing lighting in shaders, however been warned they aren't the most efficient code at times.

http://developer.3dlabs.com/downloads/shadergen/


GOCP


Generally it would be a good idea to record min, max, mean and standard deviation with your tests to provide a context for them. A histogram wouldn't be a bad idea either. I find loading performance data into a database such as MS Access to be extremely helpful. Particularly if you have to document your results.

I would be inclined to use glFinish, or a fence extension if available, to isolate just what you are measuring. Failing that I would want at least a baseline, i.e. how long does it take without what I'm testing. Also for something formal like a thesis I would be a bit more methodical. An example would be starting with one big polygon filling the screen.

You're basically building a model. You're trying to identify the parameters that are relevant to the model and how they should be used in the model. Two points don't tell you much and going from 1 to 100 cubes most likely changed a bunch of variables at once. All you do with two points is draw a straight line, but the actual curve may not be a straight line. Why not 100, 200, 500, 1000, 1500, 2000, 2500, 5000, 10000, 15000, etc. See what it really looks like.

The goal is to be able to plug some numbers into an equation and say how long it's going to take. It's no differant than research in physics, chemistry, biology, whatever. You develop a theory then run experiments to test it. Most often those experiments disprove your theory but often lead to refinement of the theory and to new theories.
Keys to success: Ability, ambition and opportunity.
I thought the fixed functionality has been implemented in shaders since DX8 class hardware.

If you wrote a shader that implemented the same algorithms used in FF, and both your code and the FF code were running on the same hardware, how would there be an increase in speed?
chances are, no.
The shader code which is used for the FFP emulation in the current generation of cards (R300 was when ATI dropped hardware FFP, GFFX was the last NV card to have FFP in hardware) is very optimised microcode, hand tuned by the guys who know the hardware.

Your shaders on the other hand are dealt with via a compiler, and while this compiler is good and getting better right now its not going to beat that code.

HOWEVER, the performance difference for well written shader code is going to be negligible, you'll start hitting other bottle necks long before optimisation makes a difference in 99.9% of cases.
Quote:Original post by darookie
Shaders can be more efficient if they reduce the number of passes required to render the scene.
In case of a pure FF vs. Shader I don't see how a shader could possibly be faster, especially since modern GPUs tend to translate FF calls to shader programs internally.
I'd rather focus on reducing passes and simply do things you cannot achieve with the FF pipeline efficiently - like post-processing effects, HDR rendering, many (point-) lights and such.
Also note that a framedrop by an amount of 8 to 10 in relation to a (artificial) frame rate >1000 is less than 1% in relative performance change (e.g. negligible).

HTH,
Pat.

PS: OGL Gurus - feel free to correct/enlighten me [smile]


Thank you all for the input i really really appreciate all your comments.
Here's what i was thinking(sorry finals and projects came at me at full force and had to drop thesis stuff for last month now i can start it up again).
I Read in one of the GLSL articles on gamedev that switching state(than using GL_color than has a cost since it switches the color state to a new color) in openGL has a cost. I was thinking maybe if i can avoid that and have my 6 colors in the shader. Then i would and pass in the variable++%6 to the shader and do the if testing and based on that i pick the color would improve performance. I am not sure if this will work or not. What do you guys think?

Also regarding the lights, any comments on that ?

Quote:Original post by GOCP
As mentioned, I doubt shaders will win doing the identical task as the FF pipeline, however they can allow you to do the same tasks in a more "clever" way, hopefully reducing overhead.

The 3D Labs shader gen program would be a good start if your trying to start out implementing lighting in shaders, however been warned they aren't the most efficient code at times.

http://developer.3dlabs.com/downloads/shadergen/


GOCP


Thanks for the reply. I am learning how to use ATI Render Monkey(figured since i have their card use their product). I didn't think it was useful until i saw that i can write shaders test them and see their affect without setting up the whole environment.
Then also Disney stopped by our college and i was asking them about their shaders useage and one of them told me that if they setup the environment it takes 40 mins or so just to see it. Shaders give them the result right away so we can see how it would look in their final renderer(which takes them 1 days or so to run).
Quote:Original post by khaleelali
Also regarding the lights, any comments on that ?

OpenGL (and Direct3D as well) provide a fixed number of lights that are supported by the hardware (using the FF pipeline). Usually this number is limited to something like 8 or so. Now imagine having a set of particles that illuminate the scene - say a swarm of fireflies or a number of candles in a room.
While the number of lights in a shader (per pass) is only limited by its max instruction count, the FF pipeline limit is fix.
Yet another good reason for shaders is faking global illumination. While the FF only supports the "ambient light" hack, shaders provide you with the flexibility of choosing from a number of different more sophisticated hacks.

This topic is closed to new replies.

Advertisement