shaders

You’ve all prob seen this question a million times over, so sorry if you have!

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!

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. 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.

[PLUG]
Have a look at www.nutty.org for some nice simple vertex program, and register combiner demos.
[/PLUG]

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

Mr “DX hater and pedantic git” Nutty

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).

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.

Thanks for you replies

Sorry about the wrong terminology, like i said before, i am just starting out on shaders

Originally posted by Nutty:
[b]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.

[/b]

I personally think RC’s are a pain in the arse all together

Originally posted by NitroGL:
I personally think RC’s are a pain in the arse all together

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

I second Zeno’s idea.

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

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… ABC needs 2 general combiners, AdotB + CdotD = AxBx + AyBy + AzBz + CxDx + CyDy + CzDz needs only one

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

Originally posted by davepermen:
just the architecture of the nvidia-boards are stupid with its register combiners… ABC needs 2 general combiners, AdotB + CdotD = AxBx + AyBy + AzBz + CxDx + CyDy + CzDz needs only one

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 ABC in one register. Its a 2 step process: multiply AB, take the result and multiply resultC.

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.

Both can be done with one general combiner and doing the mult or the add in the final combiner.
And ABC can be done all in the final combiner.

kon

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

the final combiner is no general combiner…

oki but AB + CD 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.

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 with 50fps on a huge mesh