pouët.net

I recommend using HLSL if you are %100 sure this project will die using Direct3D. If there is any little chance you convert this project to OpenGL in the future (you may need a linux port for a console machine for instance), use CG. Same applies to OpenGL and GLSL.

HLSL => Direct3D only
GLSL => OpenGL only
CG => Both

That's the advantage of CG.

That's probably half, but I've fixed stuff for ATI before by changing "1" to "1.0" in the shaders. I've also had problems with x1600 not supporting stuff I thought it would handle, I think it's more like a ps2.5 card somehow :)

On osx I've found nvidia drivers worse than ati's for a lot of things - which one is better really depends on exactly what you want to use it for. E.g. for core image, nvidia performance is terrible at times and a mid-range ATI card easily beats an nv high end card.

another one of the great delights with d3d - the hlsl compiler doesnt live in the driver. :)

blala: how do I determine if a shader is being run in software? More to the point, if the hardware can't execute a shader (e.g. not high enough shader model), why doesn't the shader THEN run on software?

@xTr1m: well, I use the following simple rules of thumb:
* if it's 30+ fps on the gma950, then it runs in hardware
* if the same thing is 1 fps on the x1600, then it runs in software

(though meantime I realized that in this particular example, the reason was probably that the texture in "render-to-texture" had a non-power-of-two size. Anyway, it doesn't help that the ATI driver lies that it supports npot textures, while in fact it does support them by software emulation)

skate: I would say CG => Neither. CG for d3d is just 'why?' while on opengl it only really works on nvidia for any more than ps2.0 things - even the nvidia compiler can't always compile it's own glsl output(!), meaning that it's only really usable with the nvidia assembly targets...

xtr1m: I don't think any of the vendors any more allows linking of programs that can't run in hardware. However, you may have something else (like texture usage) that forces you into software mode. There are some restrictions to npot on x*00 hardware.

smash: still not everything behaves the same way in d3d, but yes, at least having the syntax parser in common code would make things a lot easier..

blabla: Most of the time it IS the sloppy nvidia compiler. Generally you can say that the nvidia compiler accepts most things that makes sense, while the ati compiler follows the spec. It's quite often I can fix the (accidentially) nvidia only demos by shader replacements fixing those non-conformance errors - looking through the config file I have:
-giving integer arguments to float functions
-writing to varyings in the pixel shader
-putting non-const data in const variables
-using bitwise (which isn't allowed at all until 1.3) binary operators instead of the logical.
-mixing .xyzw and .rgba (ie x.bw)
-assignments of mixed size (ie. vec4->vec3)

Well personally I never had problems with nvidia's sloppyness (and anyway, it's so well known, people coding on nvidia should check the shader conformity with some external tool) and always have problems with the crappy ati opengl stuff which can result in the most impossible bugs. Though I have to agree that the directx solution of separating the driver from the compiler is better. But choosing between directx and opengl is the choice of windows vs. everything else, and not a choice based on technical superiority.


a restriction, like, it bloody doesn't work at all?

[by the way, if i would get a beer every time people spell my nick wrong on pouet, i would be constantly drunk]

NPOT textures only work on x1x00 for 1D and 2D textures (not 3D or cube maps) and not with repeat/mirror wrapmode or mipmapping. Guess the wrap mode is your problem - it's repeat by default..

hmm, ok, i can definitely try setting the wrap mode. Is the additional requirement of the dimensions being square an urban legend?

opengl, a library with a fucking compiler in it. That still strikes me as kind of an interesting idea.

GCC, A C compiler written in C. That still striked me as kind of an interesting idea.

What's C written in? oh it's written in C!

I heard the original c compiler was written in c too.

some nice links:
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html

Having the compiler makes opengl having sense. Lowlevel optimizations depends of hardware.
Psycho is right about nvidia/ati. ATI's compiler follows the spec, nvidia forget or add things.
I would add that nvidia doesn't follow glsl's pow spec : it says "Results are undefined if x < 0. Results are undefined if x = 0 and y <= 0." I have to admit that the spec is here a bit strange, but nvidia adopted the C's behavior and theses cases are valid on nvidia.

A/S/L??

It doesn't say it should be invalid, it says undefined. You can't rely on undefined behaviour, but compiler makers are free to return whatever they want.

I would like to be ok to consider that "undefined" should not be considered as "invalid", but then coders comply that if it works on a nvidia graphic card, the fault comes from the other glsl compilers (ati) whereas it's theses coders fault. So foolish.

We can agree that nvidia's GLSL compiler is to shaders what MSIE6 is to web, but undefined is undefined. We can have the same discussion about any other language, and the key issue is that people don't read specs and rely on online 'tutorials', cut'n'pasting, or 'it works for me' attitude. Having retarded permissive compiler certainly doesn't help, but there will *always* be differences in different implementations, and the only way to tackle this is by testing on other platforms.