Open Warfare

About ARB, uberbuffers, Cg, GLslang :
http://www.aceshardware.com/forum?read=105028575

Warning, highly flamable…

Why does this surprise anyone?

Well, maybe not the commentary on the super-buffers extension; that I wasn’t aware of. However, most of the rest was quite obvious.

Hmm … wasn’t the GL2 specification release way before Cg was even heard of?

As far as I understand what this guy is writing, he states that GLslang is far worse than Cg and only made it into GL1.5 because of 3Dlabs and ATI wanting to get an advantage over nVidia.

Of course it is true that there is a lot of marketing strategy and self interest involved in this ARB decision, but I can’t find a single point in this text that states WHY Cg is superiour to GLslang, except the argument about the experience of the creators of both languages…

For me the two languages seem equally qualified for inclusion in the core as the GL2 shading language. It is only a matter of personal preference which one is better and I can’t think of an objective argument that would make one better than the other.

I don’t know much about super/uberbuffers, but because of the lack of proper argumentation in the Cg vs GLslang case, I don’t think I can take the rest of this post very serious…

I haven’t use either HLSL, but the only advantages I’ve heard that Cg has over GLSLang are: explicit precision control and API independence. The former is only relevant for the GeforceFX, so far, and the latter isn’t a huge issue since most games seem to be sticking to one API or the other. I’ll admit that explicit precision control is definitely a good thing (rather than globally applying a precisin hint), but I still don’t see the point of fixed point precision among floating point precisions. The only advantage it has is with the GeforceFX, which is much faster with FX12 than with floating point precisions.

but I still don’t see the point of fixed point precision among floating point precisions. The only advantage it has is with the GeforceFX, which is much faster with FX12 than with floating point precisions.

You just answered your own question there dude

I’ll be disapointed if the final high level shading language doesn’t have support for different sized precision variables. Imagine writing C/C++ all in doubles… I disagree with the ARB’s decision to cut out precision types due to portability. C has different precision types, and its portability isn’t compromised.

I know that, but what really is the point of supporting it in the first place? It has the same mantissa precission as FP16, but without the high dynamic range. What would it have been like if NVidia had spent those transistors on more floating point units and just scrapped legacy fixed point precision entirely?

Bah. . . but this is an old arguement. . . and getting a little OT.

Probably because they can do more at FX12 level than FP16 level with the same number of transistors. And they probably thought ppl wouldn’t need FP16 or greater for everything. Hell, we’ve been using much lower precision for years, now all of a sudden anything that isn’t floating point is deemed not good enough.

Theres still alot of development that doesn’t really need high end precision, and for that, fixed point is great. It does the job, and its very fast.

[This message has been edited by Nutty (edited 08-11-2003).]

I’ll be disapointed if the final high level shading language doesn’t have support for different sized precision variables.

Then be disappointed: the 1.051 revision of the spec was ratified at the last ARB meeting.

Originally posted by Nutty:
[b]Probably because they can do more at FX12 level than FP16 level with the same number of transistors. And they probably thought ppl wouldn’t need FP16 or greater for everything. Hell, we’ve been using much lower precision for years, now all of a sudden anything that isn’t floating point is deemed not good enough.

Theres still alot of development that doesn’t really need high end precision, and for that, fixed point is great. It does the job, and its very fast.

[This message has been edited by Nutty (edited 08-11-2003).][/b]

i totally agree with you, nutty.
(finally, there is another guy out there who thinks it’s nice to have FP precision at all! )

Stop complaining about floatingpoint buffers and start using them!

back to the actual topic: superbuffers.
i wonder that nobody mentions one of the most obvious uses for them: skinning.
currently it is possible to do skinning on the HW but when using multipass methods (ie.with stencilshadows) you have to run the vertexprogramm in every pass. you also need a skinned version for evey kind of shader you plan to use with your skins.(and every vertex has to be computed 4 times)
anyway, with the ability to render in vertex arrays it is now possible just to render the vertex transforations into one array, and reuse them for subsequent passes with different lighting/shading programms. i am waiting for this feature for soo loong time… this feature makes geometry transformations on the GPU really usefull.

Originally posted by Nutty:
[b]Probably because they can do more at FX12 level than FP16 level with the same number of transistors. And they probably thought ppl wouldn’t need FP16 or greater for everything. Hell, we’ve been using much lower precision for years, now all of a sudden anything that isn’t floating point is deemed not good enough.

Theres still alot of development that doesn’t really need high end precision, and for that, fixed point is great. It does the job, and its very fast.[/b]

The question is though, is it worth it to support additional formats in hardware? The more transistors you spend on fixed point the less you can spend on floating point. What is preferrable, a really fast floating point unit and no fixed point, or a decently fast floating point unit and a very fast fixed point? Today this is subjective depending on what kind of work you need to do and fixed point may be useful for some. In the future though, it is unlikely that any significant amount of shaders will use fixed point. In fact, I don’t think I’ve written many shaders the last year that would work with fixed point. Then I don’t do much mainstream stuff either. But what I do today will be mainstream in a few years, and the utility of having fixed point in there will be reduced with time. The glslang language is aimed for the future rather than today’s need, so that no fixed point data type is included in the base spec makes sense.

i wonder that nobody mentions one of the most obvious uses for them: skinning.

currently it is possible to do skinning on the HW but when using multipass methods (ie.with stencilshadows) you have to run the vertexprogramm in every pass. you also need a skinned version for evey kind of shader you plan to use with your skins.(and every vertex has to be computed 4 times)
anyway, with the ability to render in vertex arrays it is now possible just to render the vertex transforations into one array, and reuse them for subsequent passes with different lighting/shading programms. i am waiting for this feature for soo loong time… this feature makes geometry transformations on the GPU really usefull.

This is only useful for the pathalogical case of multipass. Mainly, stencil shadows; I know of few other effects that can’t be done in 1-2 passes on modern hardware. Before even considering something like this, I’d suggest investing time in a different shadowing scheme that doesn’t force you to multipass so much.

In the future though, it is unlikely that any significant amount of shaders will use fixed point.

Define “in the future.” Until some form of floating-point texture compression is implemented, it is likely that textures will remain fixed-point. And, if those textures are colors on the range 0-255, then most fixed-point operations on them will work just fine.

How are you going to send your normal maps? As a gargantuan 96-bit floating-point texture, or as a smaller 32-bit texture (or, if possible, a nice 8-bit palatted one)? If you choose one of the fixed-point approaches, then fixed-point vector ops are perfect for you.

Saying that fixed-point math is going away is like saying that C shouldn’t have integer types. After all, floating point can do everything that integer can do, and if CPU’s didn’t spend all those transistors to support integer math, then we’d have faster floating-point.

The glslang language is aimed for the future rather than today’s need

Really? They didn’t aim that far into the future. ATi has to extend it in order to implement their ATI_draw_buffers extension, which, for a future-looking language, is a natural progression. So why isn’t it in the language itself?

Where’s the bindable-memory interface to vertex shaders that allows the user to have virtually infinite resources? Clearly, the API should be going in that direction. This sounds a lot like the task of a buffer-object (super-buffers should not be used for this, since you really want the ability to map the memory, considering that this data probably changes per-frame).

There are several other features that glslang religated to “the next revision.” Not too reasonable for a “forward-looking” language.

[This message has been edited by Korval (edited 08-11-2003).]

Textures may mostly still be fixed point, but sooner or later they go into some kind of math, where it is multiplied or added to some kind of floating point property, in which case it will have to be converted to floating point anyway. In the majority of the shaders I write math is the dominating part and texturing is a peripheral thing. The number of textures per surface is likely not going to increase a whole lot, but the amount of math applied to create different kinds of effects are going to go up significantly in the future.

As for your C argument, well integer != fixed point. Even C doesn’t have any fixed point data type such as those proposed for glslang. Fixed point can be emulated on the CPU by using integers however, but you will still have to normalize the result after multiplications and preamplify before divisions. Integers, unlike fixed point, are absolutely needed both on GPUs and CPUs. We need it for loops and stuff. In CPUs they have a much wider range of utilities than they ever will on GPUs though.

It may be possible that in the future it is found that fixed point would actually be useful, but it’s more likely that it’s useful only for a limited set of hardware today and none in the future. Thus it’s not a good idea to add it if we’re aiming for the future. The same with ATI_draw_buffers. It was proposed, but ditched due to lack of interest. ATi will probably add it as an extension though. Personally I have never had a good reason to use it. There are a limited set of cases where it’s beneficial, but in the majority of the cases it’s not all that useful.

I don’t know much about super/uberbuffers, but because of the lack of proper argumentation in the Cg vs GLslang case, I don’t think I can take the rest of this post very serious…

Looks like you were wrong; the article is right on the money about super-buffers. Take a look at how ATi is trying to screw nVidia yet again (and we’re the one who lose on this one): ARB_Superbuffers - all the gory details

Just FYI because seems not many people here read Ace’s Hardware (I can recommend it).

http://www.aceshardware.com/forum?read=105028622#TEXT

Check the replies too.