PDA

View Full Version : shaders



robert
01-21-2002, 12:26 PM
You've all prob seen this question a million times over, so sorry if you have! http://www.opengl.org/discussion_boards/ubb/smile.gif

How does one go about using pixel shaders and vertex shaders in OGL, i know the basics about using then in DX, but was wondering how to do this using OGL, because i really want to learn more about them but not have to goto DX!

Nutty
01-21-2002, 12:36 PM
1st get the terminology right.

Vertex Programs. In OpenGL we like to use correct meanings to things, other than made up buzzwords in other API's. http://www.opengl.org/discussion_boards/ubb/smile.gif Programmable vertex piplines do not shade vertices. Infact a perfectly valid vertex program, doesn't even have to process color, lights or texture coords at all. You wouldn't see anything tho.

Register Combiners and texture shaders are what OpenGL people call "pixel shaders". In actual fact they should be called fragment shaders.


Have a look at www.nutty.org (http://www.nutty.org) for some nice simple vertex program, and register combiner demos.


Also visit nvidia's developer site, for a huge amount of white papers n demos n stuff.

Mr "DX hater and pedantic git" Nutty http://www.opengl.org/discussion_boards/ubb/smile.gif

Korval
01-21-2002, 12:56 PM
Hey, let's not leave ATI's terminology out of this. The EXT extension that ATI helped define is called EXT_vertex_shader (I do prefer vertex program, but EXT_vertex_shader is a much better interface).

Nutty
01-21-2002, 01:03 PM
Well part of that "better" must be due to personal preference, no?

Same as people think nvasm string style RC's are better.. I think they're horribly miss-leading, and harder to understand that the Procedural method of accessing RC's.

robert
01-21-2002, 03:57 PM
Thanks for you replies http://www.opengl.org/discussion_boards/ubb/smile.gif

Sorry about the wrong terminology, like i said before, i am just starting out on shaders http://www.opengl.org/discussion_boards/ubb/smile.gif

NitroGL
01-21-2002, 06:39 PM
Originally posted by Nutty:
Well part of that "better" must be due to personal preference, no?

Same as people think nvasm string style RC's are better.. I think they're horribly miss-leading, and harder to understand that the Procedural method of accessing RC's.



I personally think RC's are a pain in the arse all together http://www.opengl.org/discussion_boards/ubb/smile.gif

Zeno
01-21-2002, 07:24 PM
Originally posted by NitroGL:
I personally think RC's are a pain in the arse all together http://www.opengl.org/discussion_boards/ubb/smile.gif

Agreed. If the register combiners could be replaced with something that has the same language syntax, flexibility, and precision as vertex programs, I'd be one happy boy.

-- Zeno

thewizard75
01-22-2002, 08:22 PM
I second Zeno's idea.

However, I think that it is probably a very complicated task...

davepermen
01-23-2002, 05:35 AM
hm.. ati has yet the asm-styled pixelshader. and .. dx has the asm-styled pixelshader. just the architecture of the nvidia-boards are stupid with its register combiners.. A*B*C needs 2 general combiners, AdotB + CdotD = Ax*Bx + Ay*By + Az*Bz + Cx*Dx + Cy*Dy + Cz*Dz needs only one http://www.opengl.org/discussion_boards/ubb/smile.gif

rc's are very powerfull (scripted or with functioncalls setup). but very complicated.. most of the WOW-demos on gf3 can be done on gf2 yet.. (or gf1). perpixellighting is not much difference on gf1 and 2.. possibly in 1 pass even, too! thats kind of funny http://www.opengl.org/discussion_boards/ubb/wink.gif

LordKronos
01-23-2002, 06:46 AM
Originally posted by davepermen:
just the architecture of the nvidia-boards are stupid with its register combiners.. A*B*C needs 2 general combiners, AdotB + CdotD = Ax*Bx + Ay*By + Az*Bz + Cx*Dx + Cy*Dy + Cz*Dz needs only one http://www.opengl.org/discussion_boards/ubb/smile.gif


IIRC, AdotB + CdotD needs 2 combiners (since you cant use the dot product and the sum at the same time)

Seems dumb? maybe yes. But when you get into the details, there is a good reason why you cant do A*B*C in one register. Its a 2 step process: multiply A*B, take the result and multiply result*C.

Without going completely overboard on the hardware (which would affect price and performance), they had to make some reasonable decisions on what to do. They decided that if you want 2 multiplies, you would have to resort to using 2 combiners. Now, they could have thrown a second successive multiply into the first combiner, but when you design hardware like this, you have to time you hardware to the longest path. If they had 2 successive multiplies, then processing would be slower for calculations that only use 1 multiple. And if you say "well they could have made it only wait for the second multiply if it is used", well then thats what the second combiner is for..only wait for the second combiner to finish if it is enabled.

kon
01-23-2002, 06:55 AM
Both can be done with one general combiner and doing the mult or the add in the final combiner.
And A*B*C can be done all in the final combiner.

kon


[This message has been edited by kon (edited 01-23-2002).]

davepermen
01-23-2002, 08:18 AM
the final combiner is no general combiner..

oki but A*B + C*D is possible in one pass..

a more vs-styled interface would be much simpler. ati designed its pixelpipeline like that, nvidia not. they designed it to give the possibility to put a sum of products in one pass but not a product of products or a product of sums or what ever. http://www.opengl.org/discussion_boards/ubb/smile.gif

and the mux is not very well done, too.. always needing to store into spare0.a is not that nice for gf2 users with 2 gc's.. normally only one comparison possible (cause normally compared with some texture-lookup..)

but anyways, it'll be replaced soon i guess.
dx has it replaced (bether, it never had those combiner-construct), ati never had, too. and ogl2 will not have it neighter. so no one will support this funny construction anymore sometimes. till then its cool how much you can press into 2 general combiners and the final one on a gf2 (perpixel normalized perpixellighting with perpixel specular and glossmap and all with selfshadowing and faked perpixel exponent!!!)

but as you know nearly no one got those huge power out of the gf1 yet because its terrible to push the equations in..

but its cool to see perpixellighened bumpmapped textured stuff on your screen on a gf2 http://www.opengl.org/discussion_boards/ubb/smile.gif with 50fps on a huge mesh http://www.opengl.org/discussion_boards/ubb/smile.gif