r300 is already opengl 2.0 compatible !

[nv30fan]

I have listen to ati net seminar at :

http://mirror.ati.com/developer/index.html

It was said that opengl 2.0 was already available for the R300, at least in their research labs.

I am wondering if ATI is going to release it when the R350 comes out , and how nvidia will respond ?.

Nvidia has done a very interesting job with Cg. Playing with it on my GF4 TI 4200 is a real pleasure. This is for me, the main reason to purchase nv30. Programming shaders in assembly for opengl is really difficult and i don't want to waste time debugging such assembly code, so i will stick with Cg.

But today 9700/9500 are really attractive but lack such HLSL in opengl, nevertheless some people such as NitroGL, Humus have done very very good job, programming demos for the r300 in assembly, but i don't have nights to do the same.

So, If opengl 2.0 is released soon, what will be the main avantage of the NV30 versus R300 ? Can we expect some kind of standardisation in opengl programming, and the death of exotic opengl extensions. If this comes true , an opengl code using HLSL opengl 2.0 will run whithout change either on a P20 , R300 and NV30 ?

There are also some differences between Cg and OpenGL 2.0, so
what is the future of Cg ?

What do you think ?

PS : Don't flame on me, it's only my second post .... and i have always used nvidia cards :) .

[nutball]

OK, don't take this as a flame, but:

a) the OpenGL 2.0 specification hasn't been ratified yet. It's only available in draft form (http://www.3dlabs.com/support/developer/ogl2/specs/index.htm). How can a part be said to be OGL2 compliant if this is the case?

b) OpenGL2.0 contains elements which R300 doesn't support. (I think the same is true of NV30). How can a part be said to be fully OGL2 compliant if this is the case?

Like I said, this isn't a flame, but it's about as true as the claims that R300 and NV30 are "fully DX9 compliant". It's a claim which, at the very least, needs to be taken bit a shovel full of salt.

[Uttar]

AFAIK, the R300 is fully DX9 compliant but the NV30 isn't because it doesn't have MRT. And it was determined you don't need displacement mapping to be DX9 compliant, BTW.
nVidia claims they think the NV30 is going to be OpenGL 2.0. compliant, but I don't think they're sure themselves.

And anyway, even if the R300 is OpenGL 2.0. compatible... Does that mean it's OpenGL 2.0. compliant? Not sure about that however, since I think there's no such thing as being OpenGL 2.0. compatible...

[nv30fan]

I definitely agree with your argumentation nutball. I was just asking opinions and reactions about claims formulated by ati . I was also puzzled by the lack of standard HLSL for opengl.

I know that OpenGL 2.0 specification has not been ratified yet, but some interesting stuff :

a) from http://www.opengl.org/developers/about/arb/notes/minutes9-18-02/meeting_note_2002-09-18.html

"GL2 Working Group
Bill Licea-Kane reported vigorous activity on the mailing list. Main accomplishments: accepted contributions with signed contributor agreements from 3Dlabs & NVIDIA, and decided to use glslang as the basis for the HLSL. Now merging issues from both glslang and Cg drafts into a single issues list. Working hard to conclude draft spec by end of CY 2002.
"

So clearly : Cg which is the opengl copy of DX 9.0 HLSL will not last forever.

b) ATI is a permanent member, very active in the ARB group,

c) NVIDIA is not yet a permanent member ,

d) I suppose that a fully compliant opengl 2.0 hardware will arrive next year, for example P20 from 3Dlabs which is the leader of Opengl 2.0 standardization group.

It is clear as you said that the "compliance" problem is very important, for example , what kind of displacement mapping has been implemented by Nvidia for NV30? Apparently it is different from the genuine one of the Parhelia or from the R300. Until DX 9.0 and NV30 are released we have to wait and see, and not accept the declarations of both companies as the only truth. Are these features gonna be used by game developpers ?

As an example : Ati has an extension for bump mapping : ATI_envmap_bumpmap
which doesn't exist in nvidia boards, and the register combiner mechanism is not available in the same way in ati cards.

Since both companies could not get 90% of the market, why are they still designing incompatible capabilities ?. Remember the DX 8.0 vs DX 8.1 compliance problem of last year, through ps 1.4 for radeon 8500 and ps 1.3 for GF 4 TI.

[Joe DeFuria]

a) the OpenGL 2.0 specification hasn't been ratified yet. It's only available in draft form. How can a part be said to be OGL2 compliant if this is the case?

I listened to the seminar a few days ago, and I think a couple things are being confused.

In the seminar, ATI stated that the HLSL for OpenGL was NOT TIED to openGL 2.0.

In other words, they made it sound very much like the HLSL for OpenGL would come out before GL 2.0 was finalized, and the GL HLSL would therefore support OpenGL 1.4.

Presumably, the compiler(s) could support any vendor specific extensions as well, so there will be a compiler for Radeon 9700 GL 1.X extensions. No word on any time frame IIRC though.

[nutball]

Originally posted by Uttar
AFAIK, the R300 is fully DX9 compliant but the NV30 isn't because it doesn't have MRT. And it was determined you don't need displacement mapping to be DX9 compliant, BTW.

OK, but (historically at least) OpenGL has not taken the pick-and-mix approach to feature implementation. It's all-or-nothing. I think that might be changing with OGL2.0, but I'm not sure.


nVidia claims they think the NV30 is going to be OpenGL 2.0. compliant, but I don't think they're sure themselves.


I guess because the spec. isn't final!!! The OGL2.0 spec in it's current draft form says that pixel shaders have access to the contents of the frame-buffer(s) and other buffers. This means you can program your own blending functions, do blending in floating-point buffers, all sorts of wonderful masking effects, etc. Everything NVIDIA has said so far, plus the fact the Cg specification doesn't offer such opportunities, makes me pretty sure NV30 isn't capable of it (which is a shame).

When I asked on the OGL2.0 discussion forum about this sort of feature, I was told "the hardware people don't want to do it, the software people say it's essential". Carmack et al. having their influence I guess.

So there you go, at least one feature currently in the OGL2.0 draft spec which all public evidence suggests isn't implemented in hardware by either NV30 or R300. (Or at least the public evidence doesn't suggest that the feature is implemented in hardware by either part, and this functionality isn't mentioned in DX9 AFAIK).

And anyway, even if the R300 is OpenGL 2.0. compatible... Does that mean it's OpenGL 2.0. compliant? Not sure about that however, since I think there's no such thing as being OpenGL 2.0. compatible...

Like I said above, historically "compliance" has meant to the OpenGL people a lot more than it means to folks implementing DirectX. But that may be changing through necessity as the hardware gets more and more flexible.

Clearly the OGL2 people have to manage the transition. There are various compatibility modes and approaches which may be "OGL2.0 compliant", but aren't "pure OGL2.0 compliant".

Great. More marketing hype to wade through. :mad: