On 25/03/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
You do bring up another issue though... I think we should decide on what the ARB backend is supposed to implement. Right now it's a bit of a mess with some parts only supporting up to ps_1.3, other parts doing ps_1.4, and some broken support for vs_2.0 added in. (eg. mova). I think that if we're going to say we don't support anything higher than ps_1.3 there, we shouldn't try to compile shaders with higher versions either.
How much does ARB_fragment_program support? AFAIK it does up to and including ps_1.4, for 2.0 some features like loops are missing. Is there anything in 1.4 that isn't supported by arb fp?
I think 1.4 should be possible to support.
IMO we should support at least ps_1.4, and if there is something that arb fp does not support write an ERR to tell the user to switch to glsl. If we have support for 2.0 things like mova(*) or someone contributes 2.0 features we shouldn't refuse that as long as it fits nicely into the code. I personally
Well, for one, the rounding for mova is wrong with ARB. I think one of the problems with the ARB backend is that it's not clear what it's supposed to support. In particular with instructions that behave differently between 1.3/1.4/2.0, that can lead to nasty bugs.
don't plan to add any tricky 2.0 or 3.0 features to the arb shader path(unless MacOS forces me to try)
While supporting OS X is cute, I don't think we should be adding hacks and workarounds to wined3d to support broken OpenGL drivers. (That goes for ATI/AMD Linux drivers as well).
(*) If we do not advertize 2.0 shaders with arb how come that some of Andras' games used mova with arb? Did the game ignore the limit and we do not complain if it violates them?
Probably