Official feedback on OpenGL 3.2 thread


#1

Latest desktop GPU functionality now fully accessible through cross-platform open 3D standard; Close alignment with OpenCL for parallel compute, OpenGL ES for mobile graphics and new WebGL standard for 3D on the Web

The Khronos™ Group, today announced OpenGL® 3.2, the third major update in twelve months to the most widely adopted 2D and 3D graphics API (application programming interface) for personal computers and workstations. This new release continues the rapid evolution of the OpenGL standard to enable graphics developers to portably access cutting-edge GPU functionality across diverse operating systems and platforms. The full specification is available for immediate download at http://www.opengl.org/registry.

OpenGL 3.2 adds features for enhanced performance, increased visual quality, accelerated geometry processing and easier portability of Direct3D applications. In addition, the evolution of OpenGL and other standards within Khronos, including OpenCL™ for parallel compute, OpenGL ES for mobile 3D graphics and the new WebGL™ standard for 3D on the web are being coordinated to create a powerful graphics and compute ecosystem that spans many application, markets and devices. The installed base of OpenGL 3.2 compatible GPUs already exceeds 150 million units.

The OpenGL ARB (Architecture Review Board) working group at Khronos has defined GLSL 1.5, an updated version of the OpenGL Shading language, and two profiles within the OpenGL 3.2 specification providing developers the choice of using the streamlined Core profile for new application development or the Compatibility profile which provides full backwards compatibility with previous versions of the OpenGL standard for existing and workstation applications.

OpenGL 3.2 has been designed to run on a wide range of recent GPU silicon and provides a wide range of significant benefits to application developers, including:
[ul][li]Increased performance for vertex arrays and fence sync objects to avoid idling while waiting for resources shared between the CPU and GPU, or multiple CPU threads;[]Improved pipeline programmability, including geometry shaders in the OpenGL core;[]Boosted cube map visual quality and multisampling rendering flexibility by enabling shaders to directly process texture samples.[/ul] [/li]In addition, Khronos has defined a set of five new ARB extensions that enable the very latest graphics functionality introduced in the newest GPUs to be accessed through OpenGL – these extensions will be absorbed into the core of a future version of OpenGL when this functionality is proven and widely adopted.
“Khronos has proven to be a great home for the OpenGL ARB,” stated Dr. Jon Peddie founder and principal of Jon Peddie Research. “Not only has the ARB has put the pedal to the metal to enable OpenGL to be a true platform for graphics innovation, but the synergy of coherently developing a family of related standards is leveraging OpenGL’s strengths - OpenGL is truly the foundation on which rich graphics for mobile devices and the Web is being built.”


#2

Maybe the most interesting progress come from all these D3D 10.1 features provided by the new extensions!

GL_ARB_sync is such a good news …

Again after OpenGL 3.1 release, I wasn’t expecting that many new features!

Deep reading of the spec in progress!


#3

I’m very happy to see where OpenGL is going, and makes me glad to see the release cycles gain so much importance recently. OpenGL is truly becoming relevant again in the multimedia and games industries.


#4

Where anisotropy in core? :frowning:


#5

I have one question:

Can we assume that GL 3.2 functionality will be exposed in all GL 3.0 capable hardware?

Where anisotropy in core?

Rob explained this here.


#6

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

Q: What NVIDIA hardware will support OpenGL 3.0, OpenGL 3.1 or OpenGL 3.2?
A: The new features in OpenGL 3.0, OpenGL 3.1 and OpenGL 3.2 require G80, or newer hardware. Thus OpenGL 3.0/3.1/3.2 is not supported on NV3x, NV4x nor G7x hardware.


#7

Wonderful now I have to spend my vacation reading the new specifics. I hate/love you, khronos. :slight_smile:

By the way, maybe it’s time to update the online documentation, it’s still at 2.1 version. :-S


#8

++

I’m generating C# bindings for the new specs as we speak.


#9

My second impression: http://www.g-truc.net/#news0170


#10

Thanks for fixing the LightProperty-instead-of-LightParameter error. This has been in the specs since the early SGI days!

A few more errors in the latest specs:

  1. “R_SNORM” should be defined in VERSION_3_1 enum. However, it’s value is not defined anywhere.
  2. “TIMEOUT_IGNORED” is defined twice in VERSION_3_2 enum.
  3. “2X_BIT_ATI” is defined twice in ATI_fragment_shader enum.
  4. “FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER” is defined twice in FramebufferParameterName enum.
  5. “RGB5” is defined twice in RenderbufferStorage enum.

Apart from the first issue (bug #195), the rest are not serious. However, it would be nice to have them fixed, if only to make spec converters, like the one that generates the C headers, simpler.


#11

Excellent! Now we can say GL rules. With GS it’s now the true multi-platform solution where we can benefit from latest hardware on all platforms, without having to upgrade the operating system. :wink:

Lets give it some time to see a good working drivers in actions :slight_smile:


#12

With GS it’s now the true multi-platform solution where we can benefit from latest hardware on all platforms, without having to upgrade the operating system.

Too bad that Win7 is almost out. GL might have gained some users if this had been out while the Vista FUD kept people using WinXP.

BTW, geometry shaders are not widely used. ARB_draw_elements_base_vertex, ARB_texture_multisample, ARB_sync, and ARB_seamless_cubemap will be far more used and are far more useful than geometry shaders.


#13

No body cared about Vista anyway…I saw all ppl complaining and re-installing XP. However, GL 3.2 will be a revolutionary change int he 3D realm. From CAD to real time simulation and games. But again we want to see good drivers.


#14

However, GL 3.2 will be a revolutionary change int he 3D realm.

How? It’s good for OpenGL, but I fail to see how this is a revolutionary change in anything.


#15

I meant to say many high-end and game developers will adopt it as soon as drivers are out there.


#16

Noticed the following whilst reading the GLSL 1.50 specs with changes (GLSLangSpec.1.50.09.withchanges.pfd).

On page 45:
The fragment language has the following predeclared globally scoped default precision statements:
precision mediump int;
precision highp float;

The float precision predeclaration is new in GLSL 1.50 and is not marked in magenta.


#17

I meant to say many high-end and game developers will adopt it as soon as drivers are out there.

Which ones? And by that, I mean the ones that aren’t already using OpenGL?

More specifically, what is it about OpenGL 3.2 that would make a game developer stop doing work on making their game, abandon Direct3D, and adopt OpenGL?


#18

Great work. Nice to see OpenGL moving forward so rapidly.

Just a question: What’s holding back incorporating S3TC into the core? Is VIA not willing to give up their intellectual property in favor of OpenGL?


#19

More specifically, what is it about OpenGL 3.2 that would make a game developer stop doing work on making their game, abandon Direct3D, and adopt OpenGL?

Based on the fact that GL 3.2 is now competent with D3D 10 or 11 and evolving rapidly, but providing there will be reliable drivers soon. D3D will not be abandoned in a day. Will never. But supporting two rendering paths is now possible.

I have experience with both APIs, and frankly choosing an API over the other is much of driver issue.

Hope IHVs work hard on good drivers.

Major CADs are now recommending D3D drivers for stability issues.


#20

Not adding too much to the discussion, but here’s my quick overview of the major new features in OpenGL 3.2 and GLSL 1.5.

http://www.devklog.net/2009/08/03/opengl-3-2-officially-released/