I know some people have been waiting for this for a while…
There seems to be an assumption that a multipass system would have to have some bloated scene management.
There are a couple of options.
-
You compile to multipass and it’s completely transparent and you send data pretty much as you do today ONCE and the driver multicasts the geometry for each pass. The granularity of this would depend on the size of the FIFO etc.
-
You specify a shader and the compiler gives you a pass count, then you apply the shader state WITH the associated pass number leaving the application free to implement it’s own multipass but still applying the right state for each pass as determined by the compiler for the platform. Applications then retain control over the granularity of the data vs state changes and are aware of the number of passes being performed.
The beauty is method 2 is not incompatible with method 1 some vendors could still implement 1 by returning a pass count of one from the compilation query.
Method 1 seems too scary for some, perhaps method 2 is an acceptable compromise?
I hoped ARB_fragment_program will be standarized interface only, with asm languages
exposed as extensions (like DirectX PS versions, or Cg profies).
But it seems they want to go beyond that: make standarized language, for DX9 HW only:
>> Pat asked if this was intended to be implementable on current devices. No - ATI, at least,
>> doesn’t plan to support ARB_fragment_program on old hardware (although current
>> implementation-dependent limits in the ARB spec are drawn from their current hardware)
So ARB_fragment_program will not support shaders of DX8 HW.
I’m disappointed, this is not progress, but repeating old mistakes.
Currently we have NV_texture_shader+RC and ATI_fragment_shader.
Result: 2 asm languages and 2 incompatible interfaces.
Probably Matrox will soon publish its MTX_fragment_shader.
Result: 3 asm languages and 3 incompatible interfaces.
Let’s fast-forward few months: finally ARB_fragment_program arrived.
Result: 4 asm languages, and 4 incompatible interfaces.
Welcome yet another code path, with ‘ARB’ label this time.
Wouldn’t it be better to have 4 asm languages, and ONE COMMON interface?
Of course, coding different paths is unavoidable, but it is poor excuse to tolerate mess in interfaces.
One is state based, other is procedural, another is textual; this is ridiculous.
DirectX proves it is possible to have single set of create/destroy/load/compile/bind commands for different asm languages.
I missed that little chessnut, ATI won’t support fragment program on current hardware but have guided the definition of the spec by the limits of their current hardware. nnnngggg…
why microsoft released dx instead of supporting gl
why nvidia released cg instead of supporting gl2
why microsoft wants to buy away arb_vp instead of letting gl live
why ati wants an own one instead of supporting the one from nvidia
and many more questions…
why?
because
“A scientist will never show any kindness for a theory which he did not start himself.” -Mark Twain
if not a sientist, why should a company, wich is only out there for money?
Originally posted by dorbie:
[b]There seems to be an assumption that a multipass system would have to have some bloated scene management.
There are a couple of options.
- You compile to multipass and it’s completely transparent and you send data pretty much as you do today ONCE and the driver multicasts the geometry for each pass. The granularity of this would depend on the size of the FIFO etc.
- You specify a shader and the compiler gives you a pass count, then you apply the shader state WITH the associated pass number leaving the application free to implement it’s own multipass but still applying the right state for each pass as determined by the compiler for the platform. Applications then retain control over the granularity of the data vs state changes and are aware of the number of passes being performed.
The beauty is method 2 is not incompatible with method 1 some vendors could still implement 1 by returning a pass count of one from the compilation query.
Method 1 seems too scary for some, perhaps method 2 is an acceptable compromise?[/b]
Method 2 would be the same as the effect mechanism in DX.
What would be the advantage of method 2? Which state changes can be controlled in a better way?
Originally posted by MZ:
[b]I hoped ARB_fragment_program will be standarized interface only, with asm languages
exposed as extensions (like DirectX PS versions, or Cg profies).
But it seems they want to go beyond that: make standarized language, for DX9 HW only:
>> Pat asked if this was intended to be implementable on current devices. No - ATI, at least,
>> doesn’t plan to support ARB_fragment_program on old hardware (although current
>> implementation-dependent limits in the ARB spec are drawn from their current hardware)
So ARB_fragment_program will not support shaders of DX8 HW.
I’m disappointed, this is not progress, but repeating old mistakes.
Currently we have NV_texture_shader+RC and ATI_fragment_shader.
Result: 2 asm languages and 2 incompatible interfaces.
Probably Matrox will soon publish its MTX_fragment_shader.
Result: 3 asm languages and 3 incompatible interfaces.
Let’s fast-forward few months: finally ARB_fragment_program arrived.
Result: 4 asm languages, and 4 incompatible interfaces.
Welcome yet another code path, with ‘ARB’ label this time.
Wouldn’t it be better to have 4 asm languages, and ONE COMMON interface?
Of course, coding different paths is unavoidable, but it is poor excuse to tolerate mess in interfaces.
One is state based, other is procedural, another is textual; this is ridiculous.
DirectX proves it is possible to have single set of create/destroy/load/compile/bind commands for different asm languages.[/b]
A few comments from the “Pat” in the quote above.
The ARB has finally standardized a text-based assembly interface in the ARB_vertex_program spec that I edited, and many other companies were involved in defining. The programming mechanisms are fairly similar to those provided in NV_vertex_program. Functionally, the API isn’t really all that different from the EXT_vertex_shader extension (they both do roughly the same things), but the programming interface is quite different. As ARB_vertex_program implementations become available, we will have a vertex programming interface that you can use on multiple platforms.
We hope to leverage that work to come up with a similar fragment program API; this effort is being led by ATI. The expectation is that for the most part, we will use the same program management mechanisms, the same text interface, and as much as possible, the same programming model. The inputs and outputs will be a little different, and fragment programs will obviously support texture mapping. The goal is that if you know how to program to ARB_vertex_program, you will pretty much already know how to program to ARB_fragment_program.
I agree that the diverse set of fragment APIs that exist today is a mess. Hopefully, this “fragmented” set of APIs won’t continue going forward, and we won’t reinvent the wheel as we add new areas of programmability.
One mechanism that hopefully will help is the “OPTION” mechanism present in ARB_vertex_program, which provides vendors with the ability to extend the programmability APIs without having to build completely new mechanisms. The language itself also has a versioning mechanism that should also allow it to evolve – programs have a “!!ARBvp1.0” prefix, which seems to suggest that there may be an “!!ARBvp2.0” or “!!ARBvp1.1” or whatever you want to call it in the future.
For now, we can’t make the old mechanisms go away, though it may be possible to re-package existing APIs in the same framework. But it won’t be nearly as easy, since the hardware capability is much more limited and the differences between platforms are more significant.
Pat
Folker, method 2 avoids the philosophical (and technical) dispute of having the driver multicast geometry to several passes. There’s an issue of granularity, buffer sizes and state thrashing, particularly when you throw modelview matrix manipulations in the mix. You must unroll one of the operations, you either thrash state changes or apply multiple matrix operations. When you give the application explicit control over the pass rendering you can leave the multipass compilation to the implementation and the application can do the first pass over the whole scene or just per object, at it’s discretion, you have all the benefits without relinquishing as much control. The overheads associated with the performance tradeoffs become much clearer (esp w.r.t. combinatorial state changes).
The advantages are obvious when you understand the main objection to OpenGL 2.
I don’t give a stuff what DX does.
[This message has been edited by dorbie (edited 07-09-2002).]
Originally posted by dorbie:
I don’t give a stuff what DX does.
allways know your enemies. 
no, but take a look at the dx effectfiles, they are really sweet… cg is bull**** compared to them (okay, vp and ps are still asm there in, but the usage is another one…)
Now I am really pissed (I suppose this last word will appear with **** on the board).
Taken from the minutes
Straw polls on 1.4 with and without various features:
As currently proposed (all features): 3 Yes, 8 No
With ARB_shadow, without ARB_vertex_program: 10 Yes, 1 No.
Without ARB_shadow, with ARB_vertex_program: 5 Yes, 1 Abstain, 5 No.
Without ARB_shadow, without ARB_vertex_program: 10 Yes, 1 No.
Now, are they really thinking about releasing a new version of GL (1.4) with just ARB_shadow ??? What’s the point ?
I thought ARB_vertex_program was the major change for GL in this new version. As far as I am concerned, I am not interested in GL1.4 with just ARB_shadow !
I can’t believe those people spend hours discussing the mighty OpenGL 2.0 when they can’t even add vertex programmability to GL 1.x !
You might argue that there is this IP issue that makes people reluctant to vote for the inclusion of the extension (which I must admit I do not completely understand) but then what is this IP exactly about (yeah pending patents, nice one !) ?
Are developers really interested in getting ARB_shadow only ? When I read the comments about the minutes, people talk about GL2.0 but don’t seem to be interested in GL1.4: guys, if GL1.x cannot evolve, I don’t think GL2.0 can even live !
Anyway, perhaps that’s me misunderstanding the minutes or something so I’d be really happy if some people can give me their views on this…
Regards.
Eric
you think gl1.4 with just shadow is useless? what do you think then about this?
10yes,1no for shadowing without vertexprogram
10yes,1no for no shadowing and no vertexprogram…
10 of 11 think both shadowing and vertexprograms are not needed for a new release…
Dave,
That’s my point: the ARB has gone crazy !
Anyway, I’d be happy to hear from IHVs how this IP issue on ARB_vertex_program influenced their vote.
Regards.
Eric
After reading the minutes again, a few other things occurred to me.
Is anyone familiar with what the “a 1:1 crosslicense” means? I can think of 2 things. Either it means:
1)“we give you a license for something you want, you give us a license for something we want”,
or it could mean
2)“we give you a license, and in return you give us a license for anything you do with it”.
I’m trying to decide whether there is something microsoft is after, or whether it just might be concerned about giving something like this away and then getting locked out of something that comes from it.
Also, it seems like nobody else on the ARB knows what the patent is or what the licensing terms are. As a result, most of them are a little nervous on voting the extension now. Yet Nvidia was gung ho about getting it voted now. Does Nvidia know something about this that everyone else doesn’t? That just seemed strange to me.
Originally posted by davepermen:
[b]you think gl1.4 with just shadow is useless? what do you think then about this?
10yes,1no for shadowing without vertexprogram
10yes,1no for no shadowing and no vertexprogram…
10 of 11 think both shadowing and vertexprograms are not needed for a new release…
As far as I undertstand this means that shadow maps and vertex programs shouldn’t be REQUIRED featutures for 1.4, but should be optional packages.
For vertex programs this makes sense because it reflects the current hardware (even the new p10 does not really fit into it), so it is no good idea to force an implementation for all future OpenGL versions.
Originally posted by dorbie:
[b]Folker, method 2 avoids the philosophical (and technical) dispute of having the driver multicast geometry to several passes. There’s an issue of granularity, buffer sizes and state thrashing, particularly when you throw modelview matrix manipulations in the mix. You must unroll one of the operations, you either thrash state changes or apply multiple matrix operations. When you give the application explicit control over the pass rendering you can leave the multipass compilation to the implementation and the application can do the first pass over the whole scene or just per object, at it’s discretion, you have all the benefits without relinquishing as much control. The overheads associated with the performance tradeoffs become much clearer (esp w.r.t. combinatorial state changes).
The advantages are obvious when you understand the main objection to OpenGL 2.
I don’t give a stuff what DX does.
[This message has been edited by dorbie (edited 07-09-2002).][/b]
I mentioned DX because it uses this technique already. For an effect object, you have Effect->GetNumberOfPasses() and you call Effect->Execuite(PassNumber).
The possibility that you can do the passes per scene indeed looks fascinating. However, I see a problem. The space where temporaitly variables are stored (e.g f-buffer) must not be destroyed between the passes. Who prevents the user from calling shader-1-pass-1, shader-2-pass-1, … shader-1-pass-2, shader-2-pass-2…
Originally posted by Eric:
I thought ARB_vertex_program was the major change for GL in this new version. As far as I am concerned, I am not interested in GL1.4 with just ARB_shadow !
Eric,
There are several extensions in the 1.4 proposal (which you can find at http://www.opengl.org/developers/about/arb/notes/OGL14-Whitepaper.pdf ) in addition to ARB_vertex_program and ARB_shadow.
I agree that excluding ARB_vertex_program and ARB_shadow make it a much less interesting minor revision. But it still may be worthwhile to give it a special subset distinction like ARB_imaging has (and perhaps remove the ARB namespace qualifiers).
“ARB Participants” (meaning anybody that wishes to sign the participants undertaking) are encouraged to make their opinions on this topic known to the ARB and other ARB participants through the participants mailing list. The ARB needs more ISV input on topics like this.
Thanks -
Cass
cool exts coming in cass… mostly i like the window_pos… why isn’t that in the drivers of nvidia yet some time? anyways, its cool to see it… the shadowingstuff, well, yep. gf2mx has no need for it 
point_parameters… rofl. thats not yet in?!
anyways, cool to read that document… how to get an ISV ?
Originally posted by davepermen:
anyways, cool to read that document… how to get an ISV ?
Dave,
You can get all the info for becoming an ARB participant from the following link.
http://www.opengl.org/developers/about/arb.html
Thanks -
Cass
Originally posted by pbrown:
I agree that the diverse set of fragment APIs that exist today is a mess. Hopefully, this “fragmented”
set of APIs won’t continue going forward, and we won’t reinvent the wheel as we add new areas of programmability.
I’m feeling a bit misunderstood (my English is still buggy).
I never doubted ARB_xxx_programs would standarize future, and stop growth of mess.
(the OPTION thing doesn’t surprise me). I just hoped ARB_fragment_program would also allow to hide todays mess.
For or now, we can’t make the old mechanisms go away, though it may be
possible to re-package existing APIs in the same framework
That’s exactly what I hoped for. “Stopping growth” of mess is not enough, IMO.
Please look at the problem from perspective of ordinary programer:
- ARB_vertex_program reduces mess in OpenGl
Having ARB_vertex_program I can literally forget NV_vertex_program and EXT_vertex_shader in my code.
Of course besides common interface i also got common asm language. But this is just a bonus.
There are some differences between Nv & Ati VS (Nvidia has state-program, Ati has negate-per-component)
and if they were more significiant, i would accept differences in their asm languages.
- ARB_fragment_program contributes to mess in OpenGl
If I decided to use it, I still couldn’t remove code dealing with interfaces of NvRC and AtiFS.
(unless I could afford to hibernate for 3 years, until todays newest HW available in shops
gets pushed out of mainstream, like TNT-class today)
So instead of collapsing 2 code paths for 2 interfaces into one, I have to fork() for one more. De ja vu.
The whole effect is exactly as painful, as adding support for yet another single IHV extension
designed for very narrow HW class. This is what i was meaning when i wrote “repeating old mistakes”.
The “ARB” label makes no difference here, it could be “S3” as well.
And peace of mind about standarized future (DX9+ HW) doesn’t help.
But it won’t be nearly as easy, since the hardware capability is much more limited and the
differences between platforms are more significant
I’m not praying for common fragment asm language for all HW. It is obviously impossible.
All i want is to go at least as far as DirectX has gone.
With little enhancements to DX8 PS syntax it is possible to include all Nvidia’s RC functionality.
I had once serious intent to write wrapper library supporting this.
For example, multiple-issue feature of RC is not a big problem for DX8 PS syntax (use “+” pairing) :
dp3 r0.rgb, t0_bx2, v0_bx2
- dp3 r1.rgb, t1_bx2, v1_bx2
- mul t0.a, t0, v0
- mul t1.a, t1, v1
- sum r0.a, t0, v0, t1, v1 /* ← yes, some discipline is imposed here */
this should be compiled to single RC stage:
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_A_NV, GL_TEXTURE0_ARB, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_B_NV, GL_PRIMARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_C_NV, GL_TEXTURE1_ARB, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerInputNV(GL_COMBINER0_NV, GL_RGB, GL_VARIABLE_D_NV, GL_SECONDARY_COLOR_NV, GL_EXPAND_NORMAL_NV, GL_RGB);
glCombinerOutputNV(GL_COMBINER0_NV, GL_RGB, GL_SPARE0_NV, GL_SPARE1_NV, GL_DISCARD_NV, GL_NONE, GL_NONE,
GL_TRUE, GL_TRUE, GL_FALSE);glCombinerInputNV(GL_COMBINER0_NV, GL_ALPHA, GL_VARIABLE_A_NV, GL_TEXTURE0_ARB, GL_UNSIGNED_IDENTITY_NV , GL_ALPHA);
glCombinerInputNV(GL_COMBINER0_NV, GL_ALPHA, GL_VARIABLE_B_NV, GL_PRIMARY_COLOR_NV, GL_UNSIGNED_IDENTITY_NV , GL_ALPHA);
glCombinerInputNV(GL_COMBINER0_NV, GL_ALPHA, GL_VARIABLE_C_NV, GL_TEXTURE1_ARB, GL_UNSIGNED_IDENTITY_NV , GL_ALPHA);
glCombinerInputNV(GL_COMBINER0_NV, GL_ALPHA, GL_VARIABLE_D_NV, GL_SECONDARY_COLOR_NV, GL_UNSIGNED_IDENTITY_NV , GL_ALPHA);
glCombinerOutputNV(GL_COMBINER0_NV, GL_ALPHA, GL_TEXTURE0_ARB, GL_TEXTURE1_ARB, GL_SPARE0_NV, GL_NONE, GL_NONE,
GL_FALSE, GL_FALSE, GL_FALSE);
(sure, it’s not very realistic, and i did’n compile that; just example)
Add to this final combiner syntax, and constant remapping for RC2.
The only serious problems are:
- “.rgba” dot3 (solution: disallow it, do allow “.rgb” only)
- collision of color-sum/fog-state with final combiner (solution: if final combiner stage is present in shader source, then
fog state is overwritten, otherwise current fog/colorsum equtation is copied into final combiner when shader is bound)
[This message has been edited by MZ (edited 07-10-2002).]
BTW, folker, I would be thankful if you cut some text you are quoting.