For a more understanding of shaders

[jide]

Hi,

I was thinking knowing them a bit more, but one of the last posts about them make me doubt.

Isn't that a shader a program running on the programmable pipelines of the graphic card ? I really think it is. But then, why would a driver choose to send the program (or a part of it) to the cpu instead of letting it to the gpu ? I can't figure out. Maybe because programmable pipelines are not terminated yet (some quiete young ?). Or is it driver issues only ? I'd like be sheded some lights here.
Then, what sort of 'command' will be run on the pipeline and what will be rejected to the depend of the cpu ?

I really think it can be a mess not knowing if a shader will run on the gpu or on the cpu. There could have many bottlenecks from this. As for why making shaders if they run on the cpu... Should someone provide two means for a same technic: one using the fixed pipeline and one using shaders, then test them and see which one is faster ?

Sorry for the so many questions. Hope someone will help me understanding them more.

Thanks

[Ysaneya]

What do you mean by "sending to the CPU" ? Shaders are running on the GPU - nowadays, even the fixed pipeline is implemented by using shaders. If a feature is not supported by the hardware, it's possible that the shader is emulated by the CPU, but it's generally too slow to be usable.

Y.

[jide]

from Korval
The glslang compiler will determine if a particular glslang vertex shader will run in software or hardware

So it seems, if a feature is unsupported, that a shader will run in software (so on the cpu side).

What I meant with send to the cpu is that if a shader is not accepted to run on the gpu, then the program will be 'send' to the cpu, so for running in software.

Thank you.

[Aeluned]

I would imagine that by the very definition of the language, all instructions written in it be required to be executed by the GPU.

I can't imagine my vertex shader suddenly sending instructions to the CPU.

[jide]

I completly agree with you Aeluned. I can't figure out what sort of pieces of shaders would run on the cpu side. This really can be troublesome.

It just seems I can't understand some posts

Thanks.

[V-man]

There are few cases that would lead to software mode : exceeding the instruction count, exceeding temp register count, using unsupported features (like texture in VS, noise function), exceeding texture indirection count.

If you want to know if your shader will run on everyones machine (GPU), then you need to do a test on that particular card.

Even if it runs on the GPU, you might get less than optimal performance if you don't follow the IHV's recommendation.

[jide]

Originally posted by V-man:
There are few cases that would lead to software mode : exceeding the instruction count, exceeding temp register count, using unsupported features (like texture in VS, noise function), exceeding texture indirection count.

If you want to know if your shader will run on everyones machine (GPU), then you need to do a test on that particular card.

Even if it runs on the GPU, you might get less than optimal performance if you don't follow the IHV's recommendation.

Thanks a lot V-man !

So, shader built-in noise functions are software (at least for the moment).
What do you mean with texture indirection count ? I guess it's not the same thing like texture units, isn't it ?

What's the IHV's recommendation (I Hardware Vender ??). I guess it's that Then I'll go and see their documentation about that.

regards

[V-man]

A texture indirection happens in 2 cases :
instruction pools
dependency chain

The first means you have a bunch of tex instruction, then some ALU inst, then tex. The tex instructions are a pool. It counts as a indirection.

The second is obvious.

IHVs have many recommendations in pdf or ppt format. I think I have 100MB of them.

"So, shader built-in noise functions are software (at least for the moment)."

I didn't say that. Some GPUs support them like the Realizm.

[marcus256]

I think you need to realize that the OpenGL specification, and the hardware that tries to implement it, are two different things.

If an OpenGL driver claims to support a certain version of OpenGL and some extensions, then it needs to follow the specification(s) to the point. Sometimes the hardware is not capable of doing all of the rendering. This does not necessarily have to be the lack of a certain function of the GL (say, clipping planes or vertex shaders), but a certain state of the GL that it can not cope with (e.g. more than two active clipping planes in combination with a vertex shader program longer than 100 machine level instructions) [NOTE: those examples are purely fictional].

In such situations, the OpenGL driver will decide what it can do (e.g. rasterization) and what it can't do (e.g. vertex processing) on the GPU, and the driver (that is running on the CPU!) will emulate parts of the GPU in software.

As you can imagine, these limitations are different for different graphic cards, depending on things like number of texturing "units", onboard video memory, and of course implementation specific limitations & features.

Usually a graphic chip is designed with more features than is exposed by the current available OpenGL version (which is why an old GeForce 256 card can run OpenGL 1.5), but also with some OpenGL functions missing (e.g. an accumulator buffer) since these are deemed "too costly for the common user, and not interesting enough to run on hardware". That is why all NVIDIA cards (at least RIVA 128 to GeForce 4) emulate accumulator buffers in software.

This usually leads to a situation where the OpenGL specification and the graphics hardware do not match in a 1:1 fashion, but the hardware is tweaked and turned by the driver to support as many situations as possible in hardware.

As for shaders, things are still not fully mature, so every new generation of hardware will support more things than the previous generation (higher instructions counts, different conditional execution methods, etc), but they will all try to implement the same specifications (e.g. vertex & fragment shaders/GLSL). Needless to say, newer cards will succeed more often than older cards...

[Aeluned]

Thank you. I've learned something.