ARBfp subset on GF2

OpenGL OpenGL: Advanced Coding
1

Hello

Does it make any sense to have a runtime ARBfp -> GF2 texture_env features converter? Personally, I think its a good idea to have such a tool. If you care about low-end users its nice to have uniform shaders for them and for FX and Radeon 9xxx users.
Cg compiles from C-like language to several ASM-based programmable shaders. But there is no support for arb_texture_env stuff. Of course, like in Cg, you would not have all the functionality fp gives, but you would describe the tex env state in a simpler way.
Do you know of any compilers like this one? And what do you think about it?

2

What about nvparse? I found it invaluable for setting up register combiners etc on GF hardware

3

Originally posted by DopeFish:
What about nvparse? I found it invaluable for setting up register combiners etc on GF hardware

But it will work only on NVIDIA HW. What I propose is a partial ARBfp comipiler that deals with both ARB extensions present on GF2-generation cards (env_combine, env_add, dot3) and vendor-specific extensions.

ARBfp is a more general interface for fragment programming. That is, you can describe all the functionality above in a particular ARBfp program.

!!ARBfp1.0
TXP result.color, fragment.texcoord[0], texture[0], 2D;

Can be expressed in OpenGL 1.2 as a TexEnv REPLACE function. And this is only a simple example.

Today, if you want to deal with low and hi-end users you must code two different paths. One requires you to write C code calling appropriate functions, while the other one deals with program objects and so on.

From my standpoint, you write one or two fragment programs for each material. If the program is simple it will run on all machines. If it cannot be expressed in GF2 functionality terms - you disable it or provide the second simpler program.

4

mhmm, I once wrote a parser for the texture environment setup using most of the ARB / EXT / ATI / NV extensions with bison and flex. Syntax (a kind of stripped down nvparse :wink: )was like this:

!!TE1.0
/* this extrapolates texture detail using lod bias. see EXT_TEXTURE_LOD_BIAS extension for details

Bn means a lod_bias of n
each texture unit should have same texture bound

1.single sharpen
res = 2*(B0 - B2) 2 + B2

2.double sharpen
res = 2*( 2*(B0 - B2) - B4) + B4

/
// single sharpening
/
{
lod_bias= 0;
next = 2*(tex0 - tex1);
}
{
lod_bias = 2;
next = prev + tex1;
}
*/

// double sharpening
{
lod_bias= 0;
next = 2*(tex0 - tex1);
}
{
lod_bias = 2;
next = prev + tex1;
}
{
lod_bias=2;
next = 2* (prev-tex2);
}
{
lod_bias = 4;
next = prev + tex2;

}

It should not take that much time to create your own version with a ARBfp like syntax.

The IHV won’t make a ARBfp like extension for the GF2 techlevel when they didn’t one for the even more capable NV20/NV25 and R200.

You can also check out the XEngine . It also provides a those “mini fp’s”

[This message has been edited by ScottManDeath (edited 12-30-2003).]

[This message has been edited by ScottManDeath (edited 12-30-2003).]

5

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.

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 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.

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.

Jan

6

Originally posted by ScottManDeath:
b
The IHV won’t make a ARBfp like extension for the GF2 techlevel when they didn’t one for the even more capable NV20/NV25 and R200.

The parser should only be done by third party developers. I dont want IHV to do this.

7

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…
NV_register_combiners
NV_texture_shader{2} (GeForce3)
ATI also has such extensions

ARB_texture_env_combine was only an example.

[b]
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.

Jan[/b]

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.