Pixel vs. Fragment Shader

[Descenterace]

My previous Shader experience comes from using DirectX 9, so I'm used to Pixel Shaders. What exactly is the difference between a Fragment Shader and a Pixel Shader, or are they just different names for the same thing? If not, are they at least capable of the same things, such as per-pixel lighting, specular and emissive mapping, and environment mapping?

Also, is it necessary for me to use the OGL Shader Language? With DX9 I used shader assembly code. I assume that OGL Shader Language corresponds to Microsoft's High-Level Shader Language? So how does OGL shader assembly code differ from DirectX shader assembly code?

I'm writing this game engine in C++, so I was quite looking forward to going back to the bare metal and writing some hand-tuned assembly code for my shaders...

[Korval]

What exactly is the difference between a Fragment Shader and a Pixel Shader, or are they just different names for the same thing?

Fragment shaders are a more accurate name for the same functionality as Pixel shaders. They aren't pixels yet, since the output still has to past several tests (depth, alpha, stencil) as well as the fact that one may be using antialiasing, which renders one-fragment-to-one-pixel non-true.

[sqrt[-1]]

For your reference:

ARB_(vertex/fragment)_shader(GLSL) ~ MS HLSL

ARB_fragment_program ~ PS2.0
ARB_vertex_program ~ VS1.1

NV_texture_shader/NV_register_combiners ~ PS1.1-PS1.3

ATI_fragment_shader ~ PS1.4

There are some differences but that is a rough guide. Note that there is very few differences in syntax for the ARB programs to D3D. (PS1.1 - PS1.4 is very different however)

Note that there is currently no OGL version of VS2.0 so you have to use GLSL to get access to that functionality.

See these sites for examples: http://esprit.campus.luth.se/~humus/ http://opengl.nutty.org/
The Nvidia SDK also has a lot of good examples.

[simongreen]

Well, there is currently no ARB extension for VS2.0 functionality, but we do have NV_vertex_program2: http://www.nvidia.com/dev_content/nv...x_program2.txt

Question - do people think there is still a need for assembly language interfaces now that we have a standard high-level shading language?

Personally, I like having the low-level control and knowing what my code is compiling to.

Originally posted by sqrt[-1]:
Note that there is currently no OGL version of VS2.0 so you have to use GLSL to get access to that functionality.

[Korval]

Personally, I like having the low-level control and knowing what my code is compiling to.

But you don't. The assembly gives you the illusion that you're writing opcodes that the hardware understands. But, it is just an illusion.

Take ATi hardware, for example. It doesn't support all the swizzle modes in fragment programs. So what looks like 1 opcode could take 2-4, if the swizzle is wierd enough.

[Descenterace]

With Assembly, you can optimise the use of temporary registers. With HLLs, people tend to do calculations in parameter lists, and these calculations might be repeated several times. A smart compiler might spot that, but I think that most won't.

Question about shaders in general: are these programs actually loaded into the graphics card? If so, how are unsupported functions emulated?

You say that HLSL makes Assembly redundant, but I think it works the other way round. Assembly does the job fine, so we don't need HLSL. It's not like shaders are particularly long and complex programs, so a C equivalent for them isn't absolutely necessary. When I work on a shader algorithm, I design the algorithm to be written in Assembly anyway, so I'd appreciate it if OGL continued to support shaders written directly in Assembly code.

Example: For the environment mapping shader I wrote today, I needed to take the square root of a value. Because there is no square root function, only a reciprocal square root, I specifically chose a formula that involved dividing by this value.
So even if shaders are written in HLSL, the programmer should at least know what instructions are available at opcode level.

[edit]
All right, I'll bite. There's no Assembly implementation of inverse trigonometric functions, and I had a cool idea that REQUIRES them. Of course, the question to be asked is WHY there's no Assembly implementation... Not even P/VS3.0 provides it.
So it looks like I'm relegated to using the *sob* High-Level Shader Language *sniff*.
[/edit]

[This message has been edited by Descenterace (edited 03-10-2004).]

[al_bob]

are these programs actually loaded into the graphics card?

Well, some form of program is uploaded to the video card. This doesn't have to correspond to the programming model exposed in the various shader extensions though. If the fragment program pipeline is actually implemented as a stack machine, then the driver will perform the necessary conversions and optimizations.

The compiled program is then sent to the hardware and could be stored in the frame buffer, just like texture, or in an on-chip cache.

If so, how are unsupported functions emulated?

For some functions, it's rather simple. Trigonometrics, for example, can be expanded into power series. So the driver can convert a COS opcode into a series of MUL/ADDs with some funny looking constants. Another method is to use a (hidden) texture, which it specially crafted so that filtering it gives an acceptable approximation to the function that needs emulating.

Not everything can be emulated though. For example, if the hardware doesn't support branches, then dynamic branching is difficult, if not impossible to achieve. With enough conditional codes, branching can be simulated at reduced speed (since all branch paths are executed).

Static branching is a lot easier - the driver can unroll loops and reorder the code so that the branches simply disapear.

It's not like shaders are particularly long and complex programs

This is true, for the time being. As hardware gets more complex and capable, shaders get longer, and thus that much less manageable when written in assembly.

[Korval]

A smart compiler might spot that, but I think that most won't.

Why? You're talking about driver developers here. They have every incentive to make sure that their compilers are as good as possible. Why do you think Intel makes the fastest x86 compiler? Besides the fact that they have intimate knowledge of their chips, they benifit from people using their compiler, so they make it the best they can.

Of course, the question to be asked is WHY there's no Assembly implementation...

Usually, assembly-style shader languages try to best approximate a range of functionally near equivalent hardware. Since no hardware of the modern generation supports inverse trig functions, there was no impetus to add them to the instruction set.

[Descenterace]

What I meant was, it might be a good idea for future hardware to include functions like these. I'm pretty sure that a chip could calculate arcsin and arccos in hardware faster than as a sequence of MADs.

I have no idea about compiler technology. I knew they were pretty incredible programs, but maybe I underestimate them occasionally.