Shaders

Where to start...

quote:

---

-HLSL is a generic term to encompass all shaging languages such as Cg.

---

As with most acronyms, HLSL actually stands for something. In this case, it's High Level Shader Language. This distinguishes it from low-level ASM-like languages such as ARB_FRAGMENT_PROGRAM/ARB_VERTEX_PROGRAM and PS 1-3 on D3D.

quote:

---

I don't know of any other languages other than Cg however.(for opengl). I don't know how this related to Direct3d, I'm mildly interested though. For informations sake.

---

You didn't look very hard did you? OpenGL has the vertex_program/fragment program languages mentioned above, and the high level GLSL. Cg works on both OpenGL and Direct3D BTW.

quote:

---

Shaders seem to be scripts executed on the GPU to modify either it's pixels or polygons. Like adding lens flare's or perhaps displacement mapping of a vert. I'm not quite sure about how far this can be taken

---

Pixel/fragment shader perform per-pixel operations, for example for phong shading. Vertex shaders perform per-vertex operations, such as skinning. The shader only has knowledge of the current vertex, plus any uniform variables that are set; It doesn't have knowledge of neighbouring vertices. Similarly, pixel shaders can only operate on individual pixels. If you want to know more, the best way to learn is to play with them.

quote:

---

Scripts seem to need to be compiled, as far as I can tell with Cg.

---

For this reason, your use of the word scripts is inaccurate. But yes, there's usually a compilation stage with the high level languages. Even the ASM-like languages need to be compiled to a certain extent, since the commands do not map directly to machine code. With the GLSL and the ASM-type languages, the compilation takes place at runtime.

quote:

---

-I don't know of any 'Open' type shading languages, ie non vendor specific, unless Cg actually is vendor agnostic. I think that the opengl2 spec will include such a language god only knows when OGL2 wil be released though...

---

The OpenGL shading language extensions were released with the GL 1.5 spec. Implementations exist, in various stages of completeness, for ATi, nvidia and 3DLabs cards. ATi's implementation is just about done now.

[edited by - benjamin bunny on May 1, 2004 8:33:27 PM]

To break it down even further:

OpenGL calls things ''programs'' rather than shaders. eg what OpenGL calls a vertex program is a vertex-shader and what it calls a fragment program is the same thing as a pixel-shader.

If you want to find out more about vertex programs and fragment programs in OpenGL I suggest you look at the extension specifications at SGI''s website:

Look for GL_ARB_vertex_program and GL_ARB_fragment_program at
http://oss.sgi.com/projects/ogl-sample/registry/

Of course, the above extensions only really document the lower-level ASM like aspects of the shaders.

and to make it completely confusing its vertex and fragment shader and shader objects in glsl.

quote:

---

Original post by benjamin bunny
Pixel/fragment shader perform per-pixel operations, for example for phong shading. Vertex shaders perform per-vertex operations, such as skinning. The shader only has knowledge of the current vertex, plus any uniform variables that are set; It doesn't have knowledge of neighbouring vertices. Similarly, pixel shaders can only operate on individual pixels. If you want to know more, the best way to learn is to play with them.

---

OK, extending that a bit, how do you do something like a gaussian blur or depth blur in a pixel shader/fragment program? You need specific knowledge of other pixels to do that. Or that wavy effect on Max Payne 2 when you're in the hospital at the start? Are these post-process effects done in the pixel shader, or through some other method? I've been wondering about this for a while. Do you just draw a huge quad over the screen, and apply the pixel shader to that?

---

Windows 95 - 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can't stand 1 bit of competition.

[edited by - iNsAn1tY on May 2, 2004 8:50:09 PM]

quote:

---

Original post by iNsAn1tY
OK, extending that a bit, how do you do something like a gaussian blur or depth blur in a pixel shader/fragment program? You need specific knowledge of other pixels to do that. Or that wavy effect on Max Payne 2 when you're in the hospital at the start? Are these post-process effects done in the pixel shader, or through some other method? I've been wondering about this for a while. Do you just draw a huge quad over the screen, and apply the pixel shader to that?

---

These are post-processing effects, like you guessed. You'd typically render the scene to a texture and then perform post processing on a screen aligned textured quad, usually with a pixel shader. I haven't seen Max Payne 2, but you could do a pretty good wavy effect by using a mesh of quads for the post-processing stage, animating them with a vertex shader.

[edited by - benjamin bunny on May 2, 2004 9:23:56 PM]

Okay I haven''t done anything with pixelshaders (having only a GeForce 2 and all), but I was under the impression you could get limited information about surrounding pixels using texture lookups in the pixel shader (similar to how you would obtain normals with normalmap lookups). Can anyone here correct me if I''m wrong? Also, does the pixel shader have access to the zbuffer? I know the best way to learn is to fiddle, but I''m waiting for HL2 and Doom3 before I upgrade

Pixel shaders have no access to surrouding pixels, because when the pixel shader is running the surrounding pixels (as in the pixels in the final image) do not exist yet. AFAIK you do have access to the Z-Buffer but only for the fragment (think of it as a potential pixel with) your pixel shader program is running for, i.e. you can change it''s depth value

quote:

---

Original post by gimp
-HLSL is a generic term to encompass all shaging languages such as Cg.

---

I could be wrong here, but i''m almost sure i''m not.

HLSL is Microsofts shader language, used in DirectX.
Cg is a shader language developed by NVidia.

Both are very similar in their syntax, so similar one could argue they are the same. I have not looked at Cg myself so i
could be wrong here. I just base this on what i have read on
these forums.

Sincerely, Allmight
AllSoft Studios

quote:

---

Original post by FReY
Okay I haven''t done anything with pixelshaders (having only a GeForce 2 and all), but I was under the impression you could get limited information about surrounding pixels using texture lookups in the pixel shader (similar to how you would obtain normals with normalmap lookups). Can anyone here correct me if I''m wrong? Also, does the pixel shader have access to the zbuffer? I know the best way to learn is to fiddle, but I''m waiting for HL2 and Doom3 before I upgrade

---

Pixel shaders can trivially sample multiple points of a given texture. That''s how the blur and similar effects are realized in PS.

-Nik

there is a very good reason why you cant get at surrounding pixel data, the data to your left and right hasnt been written yet as all the pipelines work in at the same time, so you can have 8 pixels in the pipeline at once on a 9700pro for example, thus they havent been written to the frame buffer yet.
Also, iirc all the pipelines operate in ''locked-step'', which means each pipeline is excuting the same line of code as the one next to it but with its data.

HLSL is the name given to shaders written for DX with MS''s own language, however it is also an abbreviation for High Level Shading Language, of which Cg and OGSL are both types of. confusing isnt it

To clarify, HLSL (Direct3D) = Cg (OpenGL). They''re the same. I see this as one of HLSL/Cg''s greatest strengths, and to be honest, I was surprised when I learnt that it hadn''t been chosen to be the shader language of choice for OpenGL 2.0. That went to GLslang, otherwise know as GLSL, which (from what little I''ve seen) has different syntax to, but works on the same principles as, HLSL/Cg.

Think about that though: two renderers, OpenGL and Direct3D, which use the same shaders? In fact, they both have support for the *.fx file format, which allows you to create an effect (passes, textures, bumpmaps, vertex/fragment programs, etc.) and then load it. You''d only have to write your shaders once...

---

Windows 95 - 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can''t stand 1 bit of competition.

Ah, but also consider, both ATI and Nvidia are comitted to making a fully functional GLSL implimentation.
Both are working on fully up to date OGL implimentations.
OGL can be found on every home PC going.
Therefore, just supporting GLSL will be good enuff, although i will grant you that atm, with so many pre-DX9 cards around Cg is better if you are going for a wider audicance.
(the .fx for OGL thing was also being discussed on the OGL Forums... as to if anything comes of it, well, your guess is as good as mine.. )