PDA

View Full Version : OpenGL 2.0 formally announced!



MikeC
08-10-2004, 02:28 PM
Story here (http://biz.yahoo.com/prnews/040810/sftu050_1.html) , though it's a bit thin on detail.

Kind of odd that this didn't appear on the opengl.org homepage first.

Corrail
08-10-2004, 03:05 PM
There are some features missing:
- floating point textures/buffers
- pixel memory management (either PBO or Superbuffer)
- color clamp control
...

Some extensions are already listed in the extension registry:
http://oss.sgi.com/projects/ogl-sample/registry/

ARB_draw_buffers
ARB_texture_rectangle

Korval
08-10-2004, 03:20 PM
There are some features missing:
- floating point textures/buffers
- pixel memory management (either PBO or Superbuffer)
- color clamp control
...
Regardless of the misinformation that's outthere about GL 2.0, it is nothing more than a GL 1.6; an incremental change. They just folded more extensions into GL like they always do with new GL revisions. Nothing major or earth-shattering.

Since none of the functions you are refering to (outside of PBO) has an actual ARB extension publically available, it isn't reasonable to just hurry them into the core. Let them be extensions first.

Corrail
08-10-2004, 03:29 PM
Originally posted by Korval:
Regardless of the misinformation that's outthere about GL 2.0, it is nothing more than a GL 1.6; an incremental change. They just folded more extensions into GL like they always do with new GL revisions. Nothing major or earth-shattering.

Since none of the functions you are refering to (outside of PBO) has an actual ARB extension publically available, it isn't reasonable to just hurry them into the core. Let them be extensions first.I know that OpenGL 2.0 is just one more new version of OpenGL where some extensions are pushed into the core. But the question is, which extensions are in OpenGL 2.0 core. I hope there will be an answer in the next days...

My information about OpenGL 2.0 extension was only based on March ARB notes where those extensions seemed to be in OpenGL 2.0 core.

James Dolan
08-10-2004, 03:39 PM
Either way, they really need to start speeding up this kind of thing else OpenGL is going to be left in the dust. You would think a 3D rendering API in the year 2004 would be able to adapt to new technologies faster than the years it seems to take to even ARB an extension non the less add it to the core.

dorbie
08-10-2004, 03:54 PM
OpenGL seems to be keeping pace with developments, extensions are useable and finally get into common or ARB extensions each major release after much debate. The ARB is a bunch of collaborating competitors so the situation isn't surprising. It's naive to expect anything better.

2.0 seems to put more in the core and make some formerly optional stuff mandatory, it's about time but it would never have happened if SGI, SUN and a few others hadn't been thoroughly beaten to the point where they can only afford to use the graphics chip designs of the PC commodity vendors. OpenGL implementors on the ARB tend to block anything getting into core that implies they aren't up to date, even when it is obvious they aren't. This is how the ARB works, get used to it, it won't change. What has changed is the way everyone on the ARB uses increasingly similar hardware from fewer design houses and that is probably good for the pace of OpenGL spec, although a lot of the 'big stuff' seems to be in place already (IMHO).

About the only significant thing in 2.0 that I can see is that some already popular core but optional ARB extensions are being promoted to non-optional core. There's not a lot new in there to justify the 2.0 monicker vs 1.6 IMHO. The extensibility of OpenGL has stolen the 2.0 thunder around about version 1.5.

V-man
08-11-2004, 06:20 AM
Originally posted by dorbie:
What has changed is the way everyone on the ARB uses increasingly similar hardware from fewer design housesSay what?

Korval
08-11-2004, 11:02 AM
OpenGL seems to be keeping pace with developmentsWhich OpenGL are you looking at?

OpenGL adopts things much slower than any competing API, and therefore is not "keeping pace with developments". D3D had a decent C-like shading language well before the ARB got around to approving glslang. D3D has easy, trivial, render-to-texture facilities; OpenGL still doesn't have this, either through superbuffers or through render_target.

There are a number of minor other features (the tech behind mesh instancing, etc) that are currently available, but do not have even vendor-specific extensions, let alone ARB or core.

The only forward-looking extension that the ARB is pushing is the NPOT texture.


The ARB is a bunch of collaborating competitors so the situation isn't surprising. It's naive to expect anything better.Which is what makes it that much more sad that OpenGL is slowly becoming marginalized. You'd think that this group would see this happening and try to stop it, but they're too caught up in politics and so forth to even consider it.

Cab
08-13-2004, 03:43 AM
There is a presentation (anounced at www.opengl.org) (http://www.opengl.org)) where you can see what is currently happening.
http://www.opengl.org/about/news/siggraph2004/bof2004_intro_web.pdf
It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.

By the way, (OT) finally RenderMonkey 1.5 is on the web (including the SDK).
http://www.ati.com/developer/rendermonkey/index.html

Hope this helps.

Sunray
08-13-2004, 04:03 AM
"It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc."
That's really great news!

Corrail
08-13-2004, 05:23 AM
Originally posted by Cab:
It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.This would be really great!!!

V-man
08-13-2004, 10:04 AM
I read the BOF about the ARB float buff which is great.

Also what about NVidia's EXT_render_target?


The only forward-looking extension that the ARB is pushing is the NPOT texture.
Ahem! draw_buffers!

dorbie
08-13-2004, 10:24 AM
Korval, that's an interesting point of view, but I've seen OpenGL look in much worse shape in the past. I too would like to see the vendors cooperate more, in some ways they're playing into the "big predatory monopolist's" hands, but I do see a lot of activity with OpenGL and in the final analysis plenty of cooperation (or capitulation by one side or the other on sticky issues). OpenGL tends to get the extensions it needs the only problem is there's often a bifurication before the consolodation of the API and some interesting conflicts (Cg vs glslang being the most significant IMHO). There's a lot to be happy about with the current state of OpenGL, I think things could have been much worse.

w.r.t. marginalization, I guess I don't see that but it depends where you look. With windows games probably there's some marginalization OTOH the proliferation of platforms makes OpenGL essential, D3D is a Microsoft only vehicle. Doom 3 should also herald a batch of OpenGL Windows games based on that engine. That's not the whole picture though, OpenGL is supported and remains viable & that's what counts if you're interested in freedom.

pkaler
08-13-2004, 10:26 AM
Nice to see that there is a "shader metafile" working group. It would be nice to have a standard FX file similar to CGFX and DirectX.FX.

The adoption of extensions has been steadily improving as the ARB has committed to yearly release cycles. Tools on the other hand are a different story, D3D still has standardized tools long before OpenGL.

MZ
08-13-2004, 11:14 AM
Originally posted by Cab:
There is a presentation (anounced at www.opengl.org) (http://www.opengl.org)) where you can see what is currently happening. http://www.opengl.org/about/news/siggraph2004/bof2004_intro_web.pdf
[from the document]

Why "2.0", anyway?
(...)
- Opportunity for new T-shirts!*slaps in forehead* NOW this makes sense!


Still backwards-compatible with 1.xSo was the original "2.0".


Minor clarifications to the Shading Language spec (v. 1.10) Late agreement to change the GLSL shader "object model" to match the rest of OpenGL (using Gen/Delete/Is and uint names instead of handle).I still think it was bad that ARB killed the original 2.0, but I give mu thumbs up here. I couldn't understand why ARB approved the new object model (for GLSL stuff) and at the sametime scrapped all essential extensions that would use it, and thus justify the whole object model change. Add to this the superbuffers proposals which looked like 50/50 mix of the 2.0 and 1.x design, and in result the OGL seemed to be getting Frankenstein appearance more then ever. Nice to see signs of consistence back again.


Originally posted by Corrail:

Originally posted by Cab:
It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.This would be really great!!!"great" would be 2 years ago. Now it's just "*sigh*, fine" IMO.

Korval
08-13-2004, 12:10 PM
I couldn't understand why ARB approved the new object model (for GLSL stuff) and at the sametime scrapped all essential extensions that would use it, and thus justify the whole object model change.Which, of course, explains why they just changed the object model back when they adopted glslang into the core, thus breaking quite abit of already existing glslang code.

GL 2.0 would have been a perfect opportunity to make everything use the handle mechanism. But no, they decided to stick with integers, and force silly management stuff onto the driver developers.


Many drafts of "uber buffers". In the end, felt to be too far beyond current hardware capabilities.In short: they couldn't agree on anything.


Reset to simpler "render target" approachWhich we should have had a good year or two ago. Come on, why didn't anybody think of EXT_render_target last year, or 2 years ago? It's a dirt-simple extension, and all transfering control of it to the ARB is doing is delaying its existence as part of useful code.

Corrail
08-13-2004, 01:33 PM
Originally posted by MZ:
"great" would be 2 years ago. Now it's just "*sigh*, fine" IMO.Yes, I agree. But that doesn't change the current state: ugly p-buffers. Altough this extension should be released one or two years ago this extension would be great now too.

By the way, does anyone have an idea what the "shading language meta file" include?

ar2k
08-14-2004, 01:24 AM
I am also curious to see what the ARB has in mind for the shader meta-format. If it's another .fx-style list of passes, models, and materials, I would almost say it's outside the scope of OpenGL.

It would be the equivalent of adding an ARB specification for a scenegraph or model format, certainly neat, but whatever bloated and feature-rich solution the ARB comes up with, chances are it will be easier for developers to specify their own little text files.

Just my two cents worth...

OneSadCookie
08-14-2004, 01:31 AM
It strikes me that the "metafile" thing has its place -- in GLU.

That way it's there for those that want to use it, but doesn't affect the "scope" of the GL.

Roderic (Ingenu)
08-14-2004, 01:40 AM
Originally posted by ar2k:
...It would be the equivalent of adding an ARB specification for a scenegraph or model format, certainly neat, but whatever bloated and feature-rich solution the ARB comes up with, chances are it will be easier for developers to specify their own little text files.

Just my two cents worth...Agreed, I also feel like it's outside of OpenGL scope, could see it in GLU however.

martinho_
08-14-2004, 04:42 PM
I just want to say that I think it's better to have a bad object model than having 2 mixed object models. And I don't think the handle system has ultimate benefits over the Gen/Delete/Is, futher than a bit less work for the driver developer.

V-man
08-15-2004, 06:32 AM
Originally posted by martinho_:
I just want to say that I think it's better to have a bad object model than having 2 mixed object models. And I don't think the handle system has ultimate benefits over the Gen/Delete/Is, futher than a bit less work for the driver developer.It shouldn't be more work because they can reuse the code for textureID, calllistID and such.

This is not a big deal.

There are bigger issues like the super buffer extension, which seems to be a in trouble.

Korval
08-15-2004, 11:20 AM
There are bigger issues like the super buffer extension, which seems to be a in trouble.According to the PDF, superbuffers is, effective dead/stalled/in limbo. Instead, we'll get something more like EXT_render_target, plus other extensions that add functionality to this base. This is all to the good, as EXT_render_target was a far simpler, more reasonable, extension than superbuffers. It's just that we should have had it by now.

Jan
08-15-2004, 12:24 PM
Yes, does anybody know about the state of EXT_render_target ? AFAIK even if we "get" it soon, that would only be the final spec, no? So we can assume, that it will take even longer, until we get a working implemention.
It´s really nice, to know, that we get such a clear and simple way for render-to-texture, but it is really a shame, that we didn´t get it 5 years ago.

Jan.

Korval
08-16-2004, 01:27 AM
Hopefully, we'll get a copy of the most recent meeting notes sometime soon.

The EXT_rt spec was not entirely far from final. My principle concern is that other members of the ARB don't sabotage the cleanliness of the extension by forcing a lot of extraneous functionality into it (rather than simply extending RT with another extension).

Since nVidia/3DLabs/Apple were the ones behind the original EXT_rt spec, and since nVidia is pretty quick about getting extensions into hardware, I imagine that they'll have an implementation available pretty quickly after the spec is released. ATi might take longer, but hopefully, they can leverage the superbuffers work they've done, simply converting EXT_rt commands into their internal superbuffers API (I recall that some of their drivers from a year ago did have some preliminary superbuffers entrypoints).

EvilOne
08-18-2004, 10:44 PM
It's a shame that they canceled the original 2.0 specs.

Whats really missing from my point of view are floating point buffers on ALL texture formats. Not a ultrafat überbuffer-API where the ARB needs at least two years to get it to the core, but some stuff that ist useable today as an ARB extensionor core feature, not the fuzzy mess of vendor specific stuff. I've switched to D3D (shame on me) and the support for float textures just rocks... not all of us use stencil shadows, and float textures are the way to go for shadow mapping. Another point is the overly bad support for rendering to a texture. How many extensions do I need, to just render to a texture? This sucks. The slow progress of the ARB is the main reason for me, not to use GL anymore. It would be nice to see features much faster promoted to the core or at least to ARB extensions. Also the quality of extensions should be better. Reading always: "This is left to another extension" annoys me really. GL2.0 is just another promotion of unfinished extensions to the core, when will the ARB learn to nail things down in a complete way? And having a high level language compiler at driver level is a thing I don't really like.

Just my two cents.

Jan
08-19-2004, 02:34 AM
http://pc.gamespy.com/pc/doom-3/539265p1.html

Second Video, 4th minute, 20th second.

Jan.

EvilOne
08-19-2004, 05:31 AM
Maybe you can tell, whats in the video?
So I dont't have to install ugly Qt-Player or download a 100 MB file.

bobvodka
08-19-2004, 11:14 AM
if its the bit i'm thinking of then its JC basicaly laying into NV and ATI for not working together to get things sorted out properly, in relation to render-to-texture and saying him self that it was the closest he's come to switching to D3D coz the API is such a mess in that regard

cass
08-19-2004, 12:16 PM
This is just one of those cases where the world would have been a better place if 2 years ago a couple of companies had gotten together and defined an EXT_render_to_texture extension.

Instead we tried to solve too much *and* get everyone to agree. OpenGL will grow fastest (and best) by accretion of proven extensions.
Committees are the wrong place for top-down design -- especially committees of competitors.

I sympathize with developers and indeed share their frustration with the situation. There's no valid excuse for letting this important functionality languish for so long.

Thanks -
Cass

dorbie
08-19-2004, 02:30 PM
Now if only NVIDIA and ATI could put that into practice a bit more (yep in some areas you've both done a good job). I'm still surprised glslang is viable today, so kudos for cooperating on that in the end, but to casual observers it does seem that consistently putting that sentiment into practice is the biggest sticking point.

It's one thing to complain about the ARB, but that implies NVIDIA and ATI would get on smoothly without it. Maybe for some stuff, but in other areas the ARB has forced cooperation (or capitulation).

And FWIW I wouldn't mind a bit if ATI & NVIDIA ran off with the ball and defined the future of OpenGL graphics cooperatively, from my perspective that would represent 'core' extensions, I just don't see it happening. NVAT_* could be better than ARB_ if it was guaranteed support by both, heck just use EXT, who cares.

l_belev
08-19-2004, 06:30 PM
Before 2.0 is ready, I would like to call your attention to one issue that came up recentrly in this list. It is the lack of an easy and simple way to set an origin for the vertex element calls - glDrawElements, etc. Currently one can do it by re-setting the vertex pointers with a bungh of gl calls: glVertexPointer(...); glColorPointer(...); glActiveClientTexture(GL_TEXTURE1); glTexCoordPointer();....
It would be good if some of the ARB members notice this issue and raise a debate about it at the ARB meetings before 2.0 is out, because it seems that there is a good deal of interest about it among the developers. Someone in the mailing list was already prepearing a specification draft for possible such extension, so they could take a look at it.

Trey
08-28-2004, 06:44 AM
Originally posted by Korval:
[QUOTE]OpenGL seems to be keeping pace with developmentsWhich OpenGL are you looking at?

OpenGL adopts things much slower than any competing API, and therefore is not "keeping pace with developments".


Just a question about D3D. I haven't written D3D code since 1997, but back then I remember the API changing so drastically from release to release that you couldn't count on DX5 code running on DX7, etc. Is D3D maintaining backwards compatibility these days, or have they settled on a core API?

OpenGL may never keep up with D3D on the new features, but so what? Every "next-generation" graphics card is coming out at an increasingly higher price, it takes a year or two for the technology to be affordable to the majority of 3D card consumers anyway.

Also, about "not keeping up with competitors" - what other competitor is there besides D3D? I can't think of any other API that competes with D3D, I don't see the future of GL in any kind of danger.

V-man
08-28-2004, 08:52 AM
D3D is not changing so drastically anymore, and many parts of D3D can be directly mapped to GL. It's in fact possible to automate the process of translating D3D to GL and vice-versa.

GL, like all technology, needs innovation, or else...
Cost is not relevant and it has nothing to do with what the consumer wants.


I don't see the future of GL in any kind of danger It's nice that GL2 is making headlines.

PS: the competitors will be software renderers, me thinks