OpenGL 3.2 Specification Officially Released

[phoronix]

Phoronix: OpenGL 3.2 Specification Officially Released

Last month when NVIDIA had published their first official 190.xx driver beta, it was discovered that there was early OpenGL 3.2 support. There was no OpenGL 3.2 specification out in the hands of public developers, but with NVIDIA working closely with the Khronos Group, it wasn't too surprising...

http://www.phoronix.com/vr.php?view=NzQyNw

[Kano]

190.18.03 officially supports it:

http://developer.nvidia.com/object/opengl_3_driver.html

[d2kx]

190.18.03 officially supports it:

http://developer.nvidia.com/object/opengl_3_driver.html

Good job, nVidia. Let's hope the other guys are working on it.

[Louise]

@vmware working on OpenGL 3.1 state tracker:

Reminded me that this years Black Hat revealed ways to escape from a VMware and Xen guest using 3D.

http://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html

So maybe that was why VMware bought Khronos Group. They knew the dangers of having 3D in a guest...

[BlackStar]

C# bindings for OpenGL 3.2: https://opentk.svn.sourceforge.net/svnroot/opentk/trunk

[FunkyRider]

[AMD is too working on OpenGL 3.2 for their Catalyst Linux driver, but based upon their past actions, it will likely be a few months before seeing such support.]

This is the single most hilarious statement I have ever seen in phoronix. Or should we say 'years'? LOL

[d2kx]

The past few months we saw a lot of AMD extensions released and with this release I think we got the confirmation of the full involvment of AMD for OpenGL. AMD contributions are everywhere with these releases and I actually wonder if they were more active than nVidia ... I'm really considering the RV870 to become my main development card when released!

Source: http://www.g-truc.net/#news0170

I personally am not able to comment on whether this is true or not but at least it seems they're improving.

[m4rgin4l]

[AMD is too working on OpenGL 3.2 for their Catalyst Linux driver, but based upon their past actions, it will likely be a few months before seeing such support.]

This is the single most hilarious statement I have ever seen in phoronix. Or should we say 'years'? LOL

Perhaps they'll end up dumping catalyst altogether and hoping that the open source catches up eventually. Someone should set up a pool to bet on which driver gets OGL 3.2 support first :)

Anyway, great news for Linux and NVIDIA.

[Qaridarium]

OpenGL3.2=wineexstanion for amd

wine 1.1.25 allready has the wine specifig extansion for nvidia

OpenGL3.2 brings this nvidia-only extansion to AMD Carts!

in fakt OpenGL3.2 is an powerup for catalyst and amd.


not realy for nvidia becourse wine allready has the nvidia-only wine extansion.


on openGL3.2--- amd has the chance to have the same power in WINE.

[FunkyRider]

OpenGL3.2=wineexstanion for amd

wine 1.1.25 allready has the wine specifig extansion for nvidia

OpenGL3.2 brings this nvidia-only extansion to AMD Carts!

in fakt OpenGL3.2 is an powerup for catalyst and amd.


not realy for nvidia becourse wine allready has the nvidia-only wine extansion.


on openGL3.2--- amd has the chance to have the same power in WINE.

ONLY IF - they can successfully manage to make GL 3.2 available on their driver within their card's useful life time! Without this [BIG] assumption, everything you stated above is pretty much pointless

Really, R300 don't have proper 3D acceleration and it will eventually get there, but, who cares? Is there anyone still using this model? playing games with it?

[Qaridarium]

ONLY IF - they can successfully manage to make GL 3.2 available on their driver within their card's useful life time! Without this [BIG] assumption, everything you stated above is pretty much pointless

Really, R300 don't have proper 3D acceleration and it will eventually get there, but, who cares? Is there anyone still using this model? playing games with it?

I have a X800 (r300) passiv cooled VGA cart!...

gread Opensource drivers!


there ARE OpenGL3.2 drivers in the cloused Beta programm.

and something very big is happens to!...

in the future the Opensource community will be a Big winner @AMD.

big Investments will come!

[mirv]

OpenGL3.2=wineexstanion for amd

wine 1.1.25 allready has the wine specifig extansion for nvidia

OpenGL3.2 brings this nvidia-only extansion to AMD Carts!

in fakt OpenGL3.2 is an powerup for catalyst and amd.


not realy for nvidia becourse wine allready has the nvidia-only wine extansion.


on openGL3.2--- amd has the chance to have the same power in WINE.

Sorry, I was just curious - which extension exactly helps wine in the 3D area? Perhaps you mean that many of the new features available in opengl3.2 will be of benefit to wine - but the wine devs still have to incorporate the changes into wine.

[BlackStar]

Sorry, I was just curious - which extension exactly helps wine in the 3D area? Perhaps you mean that many of the new features available in opengl3.2 will be of benefit to wine - but the wine devs still have to incorporate the changes into wine.

Several of those features (regarding D3D compatibility) have been available as extensions for some time now. OpenGL 3.2 simply formalizes those features.

[Heiko]

[AMD is too working on OpenGL 3.2 for their Catalyst Linux driver, but based upon their past actions, it will likely be a few months before seeing such support.]

This is the single most hilarious statement I have ever seen in phoronix. Or should we say 'years'? LOL

I'm not sure why this is so hilarious. After OpenGL 3.0 was released it took 6 months before it was supported by AMD. After OpenGL 3.1 was released it took also about 6 months (probably... latest driver can be used to create a beta OpenGL 3.1 context, so official support is probably close). So personally I expect it to take about 6 months before OpenGL 3.2 is supported by AMD. Just based on passed experiences.

Of course I would like to have support earlier, but at least the release of OpenGL 3.2 (with geometry shaders, texture multisampling and other nice stuff) means AMD will implement the new stuff. It might take a month or 6, but it will be there in a while, which is good to know.

[BlackStar]

I'm not sure why this is so hilarious. After OpenGL 3.0 was released it took 6 months before it was supported by AMD. After OpenGL 3.1 was released it took also about 6 months (probably... latest driver can be used to create a beta OpenGL 3.1 context, so official support is probably close). So personally I expect it to take about 6 months before OpenGL 3.2 is supported by AMD. Just based on passed experiences.

Of course I would like to have support earlier, but at least the release of OpenGL 3.2 (with geometry shaders, texture multisampling and other nice stuff) means AMD will implement the new stuff. It might take a month or 6, but it will be there in a while, which is good to know.

As far as I can see, most necessary extensions are already implemented in Catalyst. Geometry shaders will likely take the most time, but almost everything else is already supported in some form. Hopefully we'll see a beta 3.2 release in less than 6 months - around October/November or so.

Now, if only Intel would get off its ass and implement OpenGL 3.0 on its drivers (both open- and closed-source)...

[NeoBrain]

Sorry, I was just curious - which extension exactly helps wine in the 3D area? Perhaps you mean that many of the new features available in opengl3.2 will be of benefit to wine - but the wine devs still have to incorporate the changes into wine.

http://www.opengl.org/registry/specs/ARB/vertex_array_bgra.txt
http://www.opengl.org/registry/specs/ARB/fragment_coord_conventions.txt
http://www.opengl.org/registry/specs/ARB/provoking_vertex.txt
and some others as well, http://www.g-truc.net/#news0170 summarizes that quite well. Basically really mostly for D3D compatibility purposes, but that's what Wine is about after all ;)

AFAIK some of them are already used within Wine, so we just need to wait for support for these extensions in the drivers (especially in the OSS area)

[mirv]

http://www.opengl.org/registry/specs/ARB/vertex_array_bgra.txt
http://www.opengl.org/registry/specs/ARB/fragment_coord_conventions.txt
http://www.opengl.org/registry/specs/ARB/provoking_vertex.txt
and some others as well, http://www.g-truc.net/#news0170 summarizes that quite well. Basically really mostly for D3D compatibility purposes, but that's what Wine is about after all ;)

AFAIK some of them are already used within Wine, so we just need to wait for support for these extensions in the drivers (especially in the OSS area)

Ah, cheers!
Yes, this is looking to be a rather good opengl release.

[deanjo]

OpenGL3.2=wineexstanion for amd

wine 1.1.25 allready has the wine specifig extansion for nvidia

OpenGL3.2 brings this nvidia-only extansion to AMD Carts!

in fakt OpenGL3.2 is an powerup for catalyst and amd.


not realy for nvidia becourse wine allready has the nvidia-only wine extansion.


on openGL3.2--- amd has the chance to have the same power in WINE.

If you consider nvidia supporting extensions early then the others as "nvidia-only" then I guess you can say pretty much every OGL release has had "nvidia-only" extensions as they are always the first to have support for upcoming releases. Once again, if you want to develop cutting edge tech you have to use the nvidia blobs and wait for everybody else to catch up (ranging from the typical 6 month wait for ATi's blobs to years after in the OSS arena).

[BlackStar]

Just a small clarification: "Nvidia-only" has a specific meaning in the world of OpenGL. It refers to extensions released by Nvidia and not ratified by the ARB or other vendors. Note that this doesn't mean that other vendors cannot implement those extensions (it has been done before), just that it's unlikely (because they expose nvidia-only functionality). AMD and every other vendor can and do release extensions in the same spirit: "AMD_vertex_shader_tesselator" (awesome extension btw), "SGI_swap_control" and hundreds more.

OpenGL 3.2 has ratified some "nvidia-only" extensions and moved them to core (which means vendors are required to implement before they can claim OpenGL 3.2 compliance) or they have made them ARB extensions (which means that multiple vendors have agreed that this is how something should work and that they will likely implement them soon).

Wine has used some NV-only extensions to improve compatibility and/or performance with D3D. The ARB has decided that those extensions are generally useful and has promoted them.

OpenGL 3.2 is a very exciting release because: a) it brings some very useful stuff into core (base vertex index, geometry shaders, seamless cubemaps) and b) because it shows continued dedication on the part of the ARB. The ARB still has a lot of work to dispel the fears of the past (no public communication, updates delayed for years) but they are doing a damn good job right now.

Now we only need to make intel follow the lead of Nvidia and AMD. Their hardware maybe slow, but it's capable - it's their drivers that are really lacking in the OpenGL department.

[Qaridarium]

If you consider nvidia supporting extensions early then the others as "nvidia-only" then I guess you can say pretty much every OGL release has had "nvidia-only" extensions as they are always the first to have support for upcoming releases. Once again, if you want to develop cutting edge tech you have to use the nvidia blobs and wait for everybody else to catch up (ranging from the typical 6 month wait for ATi's blobs to years after in the OSS arena).

wine only make an mistake... the wine devs think that the extansions was official in the openGL ...

thats all...

[Kano]

Why is it a mistake to use the max out of existing hardware? ATI is free to add the same extensions.

[Ex-Cyber]

wine only make an mistake... the wine devs think that the extansions was official in the openGL ...Wouldn't it be pretty hard to make that mistake, considering that vendor-specific extensions have their own prefixes?

[frantaylor]

Is there any work towards "sanitizing" OpenGL? It is very hard to implement OpenGL properly in languages like java because you can pass args to OpenGL functions that will crash your program. This sort of thing does not fly in Java. If OpenGL or its wrapper were to do proper boundary checking on all its args it would slow everything down. I wonder if there is anything that can be done.

[RealNC]

OpenGL does not have to follow Java's brain damaged philosophies :D

[frantaylor]

OpenGL does not have to follow Java's brain damaged philosophies :D

Why is it brain-dead to throw an exception instead of crashing? You can recover from an exception.

If OpenGL were "sanitary" then it could be used in sandboxes for web applets and such. In its current state you have to wrap it up or else it is just a big security hole.

[frantaylor]

OpenGL does not have to follow Java's brain damaged philosophies :D

Why is it brain-dead to throw an exception instead of crashing? You can recover from an exception.

If OpenGL were "sanitary" then it could be used in sandboxes for web applets and such. In its current state you have to wrap it up or else it is just a big security hole.

It's not even just java. It is the same situation for Ruby or Perl or Scheme or python or any other interpreted language.

[frantaylor]

Have you ever profiled a 3-D app? Even with a fancy high-end card, your program spends the vast majority of its cycles inside of OpenGL calls. This means that you can write your app in a slow interpreted language and it will really not slow things down much at all.

3-D apps are all about look and it is very subjective, so you do a lot of fussing with the properties of objects to get them to look "right". This means lots of recompiling if you write in C or C++. If you work with an interpreted language you can quickly fix up the look and the action to the way you want. And THEN you can port it to C or C++ if you really want the speed.

"When writing a program, you should plan to throw the first version away, because you inevitably will, whether you planned to or not" - Gerald Sussman, inventor of Scheme and otherwise really smart guy.

If one follows his advice then one should always prototype in a nice, easy to work with language. There are enough headaches with development of new code, why give yourlself the extra burden of worrying about pointers and memory allocation when you should be focused on how your game is going to play or how your visualization is going to show the tumor cells?

The problem with OpenGL is, even your prototype app will dump core if you mess up, and you will still find yourself in gdb looking at stack traces even though you made an effort to keep your head out of the bits and bytes.

[mirv]

OpenGL is very low level for performance reasons - it doesn't suit well to make it work directly with a higher level language, and that's why wrappers / bindings exist for it. OpenGL will return error values however, and these can be checked easily enough. If the error values are not properly reported, it's not the fault of OpenGL, but rather the implementation of it.
Interpreted languages also do an awful lot of error checking internally, so wrappers could do that quite easily as well.

[nanonyme]

Why is it a mistake to use the max out of existing hardware? ATI is free to add the same extensions.It's not as long as you're mentally prepared to do things the Right Way (tm) and do distinct code paths for all vendors - read: Intel, nVidia, ATi, etc. (Like Microsoft's DirectX afaik does; Wine's devs seem to adamantly believe that they can do some uniform solution which is obviously wrong - from what I've heard they seem to believe it should be enough they just do the nVidia codepath and it's on the responsibility of driver vendors to port their drivers. This is very likely to give you reduced performance with non-nVidia hardware even if the driver implementation is as good as with nVidia. Of course, who wants to do three - or five if we count open ATi and nVidia drivers - times as much work?)

[Kano]

I am sure that will be done in time for fglrx with opengl 3.2 support. As NV provides now already those test drivers wine could adopt that new codepath and fglrx users will be happy when ATI manages to provide that too. Currently it does not matter in which way the functions are used as they run only on NV hardware.

[Qaridarium]

Why is it a mistake to use the max out of existing hardware? ATI is free to add the same extensions.

not a problem... just a mistake,, becourse wine devs don't want suppor nvidia only-