Last ARB meeting

[CMKRNL]

Well the latest ARB minutes aren't up yet at opengl.org/developers/about/arb.html#Notes, but here are some highlights:

- GL2 High Level shading language had two proposals, one from 3DLabs and the other from nVidia. There was a vote held earlier in the month where glslang was unanimously chosen (well, nVidia voted for Cg). Things are moving along at a very good pace and they hope to have the 1.4 extensions before the end of the year.

- ARB_Fragment_Program approved with unanimous vote. The specifications are already up on opengl.org.

- Working group for advanced vertex programs with branching support to be led by nVidia

- 3DLabs proposed a vertex array object extension that consolidates the existing extensions from ATI and nVidia. ATI and nVidia are also working together to provide a unified vertex array object extension

- Votes were held for adding three new permanent members, but none passed.

- Next ARB meeting to be hosted in Santa Clara by nVidia

 

[gkar1]

What are the main differences between "GL_ATI_fragment_shader " and "ARB_Fragment_Program"?

Or what's been added if anything. Bah, should have gone to link to read up specs.

 

[KimB]

GL_ATI_fragment_shader is the Radeon 8500 pixel shader extension. GL_ARB_fragment_program is the 9700 extension. I would expect that nVidia will support it as well (in conjunction with their own extensions).

On the programming side, I think the main difference appears to be that fragment_program uses a method more like DX8 and nVidia's extensions that parses a text file for input, as opposed to the horrible function-based parsing that ATI used previously.

After a very, very quick skim, it also looks like ATI introduced a rather interesting method for making it easy to multipass.

 

[gkar1]

Cool, thx for the info!

Altho i didn't like to see this at all:

IP Status

Microsoft claims to own intellectual property related to this extension.

 

[KimB]

- GL2 High Level shading language had two proposals, one from 3DLabs and the other from nVidia. There was a vote held earlier in the month where glslang was unanimously chosen (well, nVidia voted for Cg). Things are moving along at a very good pace and they hope to have the 1.4 extensions before the end of the year.

In a way this is good. As I stated before, I really liked the idea that 3dlabs' programming language should be usable on any hardware...the assembly wasn't to be standardized. As a side note, I hope that nVidia takes the Cg initiative a step further and modifies it to conform to the new OpenGL standard on the OpenGL side of things, but keeps the DX compatibility intact.

- Votes were held for adding three new permanent members, but none passed.

Heh, with ATI on the board, somehow I don't think nVidia will ever get on...

 

[Snap]

Heh, with ATI on the board, somehow I don't think nVidia will ever get on...

Well, you may wish to remember that there are several other organisations in that ARB and they were the ones who voted ATI in and not NVIDIA, so I don't think ATI are can necessarily be accused of being the ones that don't let them in!

 

[Humus]

On the programming side, I think the main difference appears to be that fragment_program uses a method more like DX8 and nVidia's extensions that parses a text file for input, as opposed to the horrible function-based parsing that ATI used previously.

I'm not aware of any nVidia fragment extension that takes text input, unless you're talking about NV30 stuff.

 

[DemoCoder]

The 3dlabs language is nice, but there a couple of things missing and some irritating things.

1) they might get rid of swizzle notation and require constructor/function syntax in place of it. I hate this as it makes code less readable and more verbose, and if you were used to writing DX8 shaders it doesn't map as nicely. Also, it won't match up with the syntax used by DX9 HLSL/Cg nor even some Parallel-C variants.

Consider

a = b.wzyx + c.yxzw

vs

a = vec4(b.w, b.z, b.y, b.x) + vec4(c.y, c.x, c.z, c.w)


2) No user defined structures. e.g. no C "struct", see #4

3) function syntax uses pass by reference instead of pass by value

4) no covariant return type. if a function returns more than one value, must use "pass by reference" with "output" keyword ala PL/SQL stored procedures.

5) #3 and #4 complicates optimizating compilers. Pass by value would be cleaner.

6) no "hint"ing ability for reduced precision datatypes. DX9 HLSL and Cg both allow you to say "this floating point computation only requires half precision if you can do it" It's hard to impossible for a compiler to determine this.

7) BUT, (primarily because of the P10), *integer* is included. Of course, this will be promoted to float/float4 on all known DX9 level hardware. Hmmm... Good for 3DLabs, bad for mostly everyone else. i++ and i-- will be more efficient on those platforms unless the compiler can detect that they are being used in a loop situation.

8) Can't treat packed data-structures as arrays or convert between packed representations in general IIRC.


There are some other things. Really, Cg/DX9 HLSL/3DLabs are not very far apart. They should just get together and combine the best of all of them. The lack of precision hinting, for example, will annoy devs who can get it in DX9 HLSL. Even Java has this capability with "strictfp" vs non-strict FP as does Perl.

 

[Rodéric]

isn't it the 'latest' ARB meeting, and not the 'last' ?

 

[Nagorak]

Cool, thx for the info!

Altho i didn't like to see this at all:

IP Status

Microsoft claims to own intellectual property related to this extension.

I think Microsoft claims to own intellectual property to toilet paper too. Just think, if that stands up in court, we'll all have to cut MS a check whenever we wipe our asses.

 

[PSarge]

The 3dlabs language is nice, but there a couple of things missing and some irritating things.

Pretty much everything you've identified is being discussed within the ARB at the moment (in fact you're hit rate is superb), but to take a couple of points in particular.

1) they might get rid of swizzle notation and require constructor/function syntax in place of it.

[...snip...]

Consider

a = b.wzyx + c.yxzw

vs

a = vec4(b.w, b.z, b.y, b.x) + vec4(c.y, c.x, c.z, c.w)

Reading the discussions recently I would say that the b.wzyx notation is going to be in the language. It seems to be generally viewed as a desirable thing. The notation isn't set in stone yet, but it's likley to be something similar to what you've written.

2) No user defined structures. e.g. no C "struct", see #4

Not definate if it will make it or not at the moment. Even if it doesn't go in preparations are trying to be made that it could be added in an orthogonal way at a later point.

3) function syntax uses pass by reference instead of pass by value

I think there's a motion to change this.

6) no "hint"ing ability for reduced precision datatypes. DX9 HLSL and Cg both allow you to say "this floating point computation only requires half precision if you can do it" It's hard to impossible for a compiler to determine this.

This is currently under heavy discussion. The main problem is that if your hardware implements only higher precision floats, then should you have to pay an extra penalty when a "half float" is used in order to emulate the accuracy and overflow characteristics of the smaller type.

Personally I think we'll end up with a "short float" and "float" both of which have minimum range/accuracy attributes, but are allowed to exceed them. It's then down the the shader writer to ensure that his shader doesn't require more range/accuracy than the minimum specified, otherwise it'll run on some chips and not others.

7) BUT, (primarily because of the P10), *integer* is included. Of course, this will be promoted to float/float4 on all known DX9 level hardware. Hmmm... Good for 3DLabs, bad for mostly everyone else.

Actually the original 3Dlabs proposal did not have integers in at all, but they were deemed too useful for loops, array indexing, etc... Integers up to the size of the mantisa can be implemented in a float without problems.

There are some other things. Really, Cg/DX9 HLSL/3DLabs are not very far apart. They should just get together and combine the best of all of them.

That's exactly what's going on right now. There are ISV's contributing to the discussion as well, and more would probably be welcolmed. This isn't a closed circle of companies/people doing the developing. If you have points you want to raise there are ways of making yourself heard.

edit: Just to be clear. I'm not really involved in the GL2 discussions. It's just I have access to the mailing list where most of the points are raised. What's above is just the impressions I've got from reading it.