Originally posted by JanHH:
hm… you cannot use “uniform shaders”, or rather, if you do, you would restrict fx/radeon users to the rendering possibilities of a gf2 chip.
I believe we have misunderstood. By the “uniform shaders” I meant that you use only ONE tool (for example ARBfp shader editor).
As far as I know, ARB_FP is way more powerful than ARB_texture_env_combine!? So you could only translate a very small subset of fp to this. And because of that, you would have to write separat shader programs for gf2 and fx/radeon.
And thats the point. You have to scenarios. First: you have simple geometry (all the stuff that can be done on gf2 like dot3 bumpmapping, pp diffuse) - you write only one shader. Second: you have complex geometry - you create two shaders - one for fx/radeons and one (simplified) for gf2 (and if it cannot be done in a single pass, you write two or more shaders and connect them by blend settings (colorwrite enables, blending factors). Or maybe the parser can deal with it and detect such an issue and automatically split the arbfp program to multiple passes.
And ARB_texture_env_combine is not very hard to set up, especially when you only have two texture units, I think the idea is rather pointless.
What do we have…
ATI also has such extensions
ARB_texture_env_combine was only an example.
Another point is the fact the you might need more rendering passes on lower level hardware, and I do not see how you want that to be controlled by such an FP wrapper.
I have to admit that I do not really see an need to support gf2 at all anymore. You could design your own shading language and translate that to ARB_FP or register combiners, or something like that.
I dont want to have yet another shading language. I want to base on an existing functionality.
The reason I have started this thread is that I have made some research in this area and found the results useful. And thats why i ask if it has any sense and if such a parser doesnt already exist to avoid reinventing the wheel.
The translator I have made (ARBfp -> gf2 fixed pipeline stuff) is very simple and powefull. It uses its own micro-assembler to describe both the ARBfp opcodes functionality and fixed pipeline functionality. Matching is done by comparing compiled ARBfp with existing modules. Yet it requires a lot of work to describe more advanced extensions.
So before I get to the job I make this discussion. Thank you for you post.