Current GL 3 .0

[glfreak]

What's the current status of OpenGL 3.o drivers and how users accepting it in terms of performance and an alternative to D3D 10 - 11?

When is OpenGL 3.1 spec expected?

Any promising future?

[Timothy Farrar]

To my knowledge GL 3.0 drivers are available from both NVidia and ATI. I haven't used/tested the ATI drivers yet, but it seems as if they have support for PC/Mac/Linux.

Who knows when Intel will be on board?

[Groovounet]

lol

Intel doesn't even support vertex shader ... They reach GLSL fragment shader few months ago.

Intel? I sooooooo don't care!!!

[Brolingstanz]

Intel on OpenGL 3.0

- Intel is excited about OpenGL 3.0
- We look forward to a strong OpenGL future
- Look for Intel support of OpenGL 3.0 on future platforms

This according to the vendor announcements at the Siggraph BOF.

[Groovounet]

Yes existed ... well nothing is existing when I'm thinking of Intel graphics chips.

[Stephen A]

Until you find yourself stuck with supporting an OpenGL app on intel hardware. You can imagine how fun that is not.

And the sad thing is that intel has about 1/3rd of the GPU market.

[PkK]

I'm tired of people spreading misinformation about Intel's graphics chips. They may not be the fastest, but that's no reason to claim they don't support features, which they clearly support. However it seems to me that the hardware could support even more than what's exposend in the drivers (geometry shaders, RGBA16 buffer objects, etc).

Here's part of the glxinfo output on the system on which I'm writing this. As you can see, GL_ARB_vertex_shader is in the extension list even though I have an old Intel 965 graphics chip.

OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114
OpenGL version string: 2.1 Mesa 7.3
OpenGL shading language version string: 1.10
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite,
GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos,

[Groovounet]

This is direct information from Keith Packard at Fosdem 2009 conference, 1 week ago.

+

The extension string of GL_ARB_vertex_buffer_object is present since years ago but last time I tried to use it (1 year and half) I had a null pointer for glGenBuffer ...

I unfortunalty had to support this chip for the project I was working on at the time, after a lot of issue I choose to use an OpenGL 1.1 code pass for any Intel chips.

So yes I claim it: They are close to stone edge in term of drivers. The hardware is fine (expect some terrible design issues (have a look on Fosdem X.org presentations for more information)) and yes is support even Geometry Shader with Direct3D. It's a Direct3D 10 chip!

The issue is the software! Keith Packard have a really good understanding of this issue but at Intel, it seams that a policy is "if we could do it in software, it's not a big deal". Other graphics chip companies choose to do it in hardware.

I more or less trust ATI with their OpenGL drivers. They might be slow to implement feature but it's going to happen. With Intel ... well, it's so not going to happen and to conference I had was such a demonstration.

By the way, they just complete there support of Framebuffer object!
...................................

Intel => I don't care! => OpenGL 1.1

[V-man]

The best way to support Intel is through D3D. Personally, I beleive that you should use the tool that works best.
As for Pkk post, on Linux things are different. The Intel drivers are corrected and updated by the open source community... in other words, things get done.

[Stephen A]

My experience has been that intel drivers fail to compile bog-standard GLSL programs (typical vertex shader & per pixel lighting) that run perfectly fine on 7 year old Ati and Nvidia hardware. GL2.1 support - yeah right.

Then you have artifacts when using 8bit alpha textures on their lovely 865 and 915 IGPs (workaround: use a RGBA texture or use another card.)

Intel's D3D drivers is passable. Their OpenGL support is atrocious. Just take a look at the workaround list in Google Earth, it's quite enlightening! :)

Groovounet's got this just about right: Intel => GL1.1 codepath => pray it works.

@VMan: sometimes you have to support an existing or a cross-platform codebase, where writing a D3D renderer is not an option...

[_NK47]

Intel drivers are top notch at crashing and showing blue screens. don't see something worth using coming even close to 3.0 on Intel, they should fix/implement 1.5 issues first.

[glfreak]

Based on my experience with Intel's video hw, D3D is the inevitable resort after seeing pink backgrounds, black textures...etc. or use minimal OpenGL 1.1 functionality with worst rendering quality. But if things work fine in D3D this means it's driver issues, where D3D driver is much easier to implement and requires less burden.

I would say unfortunately, but it's fortunate for our project, that we have to port our OpenGL stuff to D3D, in order to cover consumer level hardware, especially that comes with embedded video boards.

Hate to say it but GL is becoming more like programming punch-cards, being designed for the X Window stuff, 1 century old technology.

It's not the specification, it's the implementation.

[_NK47]

very true. D3D us supported in the first place, observed many times on Intel and ATI. programming in D3D isn't much of an issue on Linux either since Wine supports alot these days (OpenGL though). confused myself what to support more, alternatively 2 API's but one is always somehow dominating in code design. AFAIK D3D is used far more especially in the games market making it the first choice to support and maintain quality drivers.

[glfreak]

OpenGL and only OpenGL! :D

[knackered]

quiet on these boards these days...rob barris noticeable by his absence.
shame, it was fun while it lasted - great memories of the emergence of programmable shading that came to GL first through extensions. Special times.
Now it's just the mac/linux 3d api. We're even moving to d3d now stereo's supported in nvidia's driver. Never thought I'd see the day. Maybe one day we'll do a linux version of some of our software, and I can relive my youth.
The ARB is beyond contempt.

[ScottManDeath]

Is the stereo NVIDIA D3D support a generic D3D thing, or via NVAPI and/or driver backdoors?

[Rob Barris]

quiet on these boards these days...rob barris noticeable by his absence.
shame, it was fun while it lasted - great memories of the emergence of programmable shading that came to GL first through extensions. Special times.
Now it's just the mac/linux 3d api. We're even moving to d3d now stereo's supported in nvidia's driver. Never thought I'd see the day. Maybe one day we'll do a linux version of some of our software, and I can relive my youth.
The ARB is beyond contempt.

Hi knackered,

The OpenGL 3.0 specification was released in August 2008. At this point in time (Feb 2009) there are two feature-complete OpenGL 3.0 driver sets available, one from AMD and one from NVIDIA, on Windows and Linux if I am not mistaken.

Concurrently, work on the 3.1 spec began after the 3.0 spec was completed last summer, and has been progressing ever since. The participation level in those working group meetings has been steady and consistent (myself included).

If you have specific features you need improved or added to GL, please be sure to bring them up in the "talk about your applications" thread since we keep a close eye there for ideas that can and will feed into subsequent revisions.

In short. our views of reality may not match 100%.

[Jan]

Yeah, it's "feature complete" (it does support that new context-creation extension ...), but the feature-set is so meaningless and the API itself is so horribly cluttered, that no one cares anymore. Right now i gain nothing from adding GL3 support. That's really the main problem here.

Jan.

[Rob Barris]

Just out of curiosity, when you say the API is cluttered, are you referring to features or functions that are part of the 3.0-deprecated set, or something else specifically ?

(Since one of the key motivators behind the definition of the deprecated feature set was to thin out the API's complexity over time, this is important for me/us to grasp the discontent here)

Plainly as revisions of the API appear that remove clutter (by removing deprecated functions from the API) - you'll see more new functionality and less clutter.

[Jan]

When you remove all the deprecated stuff the API gets a lot cleaner. The problem is, that

1) there has nothing been removed directly, so a GL 3.0 driver is still a mess

2) major vendors already announced, that they won't remove stuff in the future either

From history we know, that OpenGL is a "soft" or "weak" spec. If some vendor decides, that he doesn't fully agree with something, he simply will do it the way it's not actually meant to be played.

I say GL3 is cluttered, because for me it is still 2.1. I can create a GL3 context, but what then? Nothing changes, except for some "guidelines", but i don't need an extra context for that.

What we really need, is vendors exposing drivers, where i can set the "forward compatible"-bit and it will actually remove all the deprecated stuff. As a consequence the driver should also become more reliable, hopefully.

Feature-wise even 2.1 is not up to D3D10. Yes, if you take all the NV extensions, it mostly is, but that doesn't really count. what's missing in core gl is stuff like custom resolve for multisampling, mixed FBO formats, conditional render, direct state access (!! for everything!), geometry shaders and some other things. And for GL3's sake, don't bother about GL 2.1 with it.

If i really wanted to work with the non-deprecated subset of GL3, i would really need the direct-state-access extension to work for everything, so that might be something to take special care for.

Jan.

[Groovounet]

If i really wanted to work with the non-deprecated subset of GL3, i would really need the direct-state-access extension to work for everything, so that might be something to take special care for.


Agreed, DSA is the best thing that happen since ... GLSL!
It's amazing to see how small is the subset of the API can become when you use all those great extensions DSA and bindable buffer.

I think, it would be so great to have a simplified API but those days what I really waiting for is:

1 - bindable buffer ♥
1 - DSA ♥
3 - a debugging profile

[Brolingstanz]

Second that list.

On the debug profile, I would like to see something similar to d3d10's infoqueue. Basically it's just a context wide info log the driver can dump messages, performance tips, warnings and errors into. This comes in awfully handy.

[Stephen A]

Out of curiosity, which vendors support DSA? For me, this is the single biggest reason to move to GL3 (everything else is the same old mess as GL2.1).

[martinsm]

Afaik, currently only NVidia on GF8x and above.

[V-man]

Out of curiosity, which vendors support DSA? For me, this is the single biggest reason to move to GL3 (everything else is the same old mess as GL2.1).

DSA is not part of GL3. It is written to take into account the fixed function pipeline stuff like glMatrixMode

[Rob Barris]

Just to touch on some of the items mentioned above -

conditional rendering - this is in GL 3.0 already. Shipped.

buffers for uniforms - you will see something in GL 3.1 in this area.

"mixed FBO formats", there are some things that are relaxed under GL3 and GL3 capable hardware - it would help if you could elaborate on the usage you have in mind (see http://www.opengl.org/registry/specs/ARB/framebuffer_object.txt).

Geometry shader - not in the core spec in 3.0, only a shipping extension on NV at the moment. An ARB-neutral version of the GS extension has been posted here: http://www.opengl.org/registry/specs/ARB/geometry_shader4.txt

I'd like to see a lot of the DSA concepts in GL as well. It's a topic that has a reasonable level of interest in the working group.

Custom resolve for multisampling, thanks for pointing that out.

(edited per correction regarding GS on AMD HW)

[martinsm]

Geometry shader - while not in the core spec in 3.0, it is a shipping extension on both NV and AMD GL3 drivers AFAIK.

No, AMD has no support for geom shaders in 9.1 driver.

[Rob Barris]

Geometry shader - while not in the core spec in 3.0, it is a shipping extension on both NV and AMD GL3 drivers AFAIK.

No, AMD has no support for geom shaders in 9.1 driver.

I appreciate the correction, will ask them about that.

[Stephen A]

DSA is not part of GL3. It is written to take into account the fixed function pipeline stuff like glMatrixMode

I gather it won't be in core GL3.1, either? Any chance we'll see an implementation outside nvidia any time soon?

[Brolingstanz]

If enough people make a big enough stink about it you bet your boots we'll see it ;-)

[Rob Barris]

One thing to keep in mind is that the GL spec development plan has been re-worked to provide a more regular series of progressive improvements.

If a particular feature pops up too late or is too controversial to adopt in release N, it goes in a holding bin for consideration in N+1. A couple features that are going in 3.1 were of exactly this class, we originally wanted them for 3.0 but they didn't lock down in time.

DSA is currently a pretty big extension in part because it is written against the complete set of historical GL API's, I could advocate for a leaner version of it to integrate against non-deprecated features in a later revision of the core spec. That said there would be nothing stopping vendors from shipping it in extension form before that time (even beyond NVIDIA) if consensus was reached on a common extension definition.

[Rob Barris]

Geometry shader - while not in the core spec in 3.0, it is a shipping extension on both NV and AMD GL3 drivers AFAIK.

No, AMD has no support for geom shaders in 9.1 driver.

Check the Catalyst 9.2 drivers ?

[Groovounet]

Sound good! Thanks so much Rob for this feedback, I think it's just what the community was expecting!

[martinsm]

Rob: I checked, still no geometry shader extensions (ARB or EXT).

[Chris Lux]

Custom resolve for multisampling, thanks for pointing that out.

i think at least nvidia has support for that:

http://www.opengl.org/registry/specs/NV/explicit_multisample.txt

[Brolingstanz]

Yup, but I believe the original suggestion was for future core additions, not additional extensions. With this and few other items in the GL3.x bag we're more or less on par with DX10's feature set - more or less.

[Groovounet]

What do you expect to do with such feature?

[ScottManDeath]

But NV_explicit_multisample is ugly. Compare this to 2D multisampled texture [arrays], and you see what I mean. NV_explicit_multisample looks like the easy way of getting basic functionality done, without having to do much work to make it orthogonal.

So when considering this for core, please make it shiny as D3D10 :)

[Groovounet]

That's what I don't really understand: What the point of having 2D multisampled texture arrays? I might be interested to control how the multisampling is resolved but this would be what? An access to multisampling data? Is there any expectation for deferred rendering antialiasing?

[ScottManDeath]

Well, if you want to do HDR and MSAA, you want to have control over the MSAA resolve, to do the tone mapping before you do the MSAA resolve:

E.g. take the following 4 samples of 1 pixel, by rendering a triangle edge into a floating point render target.
0, 1000,
0, 1000,

If you do the MSAA resolve, you get (0 + 0 + 1000 + 1000)/4 - 250, which could get tone mapped to a very bright value, e.g. 1.

Now if you do tone mapping first, you get ( tonemap(0) + tonemap(0) + tonemap(1000)+ tonemap(1000))/4 = ( 0 + 0 + 1 + 1)/4 = 0.5, a medium intensity value, this way properly anti aliasing the edge.

For the latter, you need access to the individual MSAA samples, e.g. via 2D MSAA textures.

Or if you want to have a stencil routed k-buffer: http://developer.download.nvidia.com/SDK...utedKBuffer.pdf (http://developer.download.nvidia.com/SDK/10/direct3d/Source/StencilRoutedKBuffer/doc/StencilRoutedKBuffer.pdf)

[Groovounet]

Have you some screenshots that demonstrate the result? I understand the theory but in practice, I'm not really sure.

[ScottManDeath]

http://developer.amd.com/Assets/Harnessing%20the%20power%20of%20DX10.pdf

Slide 18

[Groovounet]

All right, we definitely need it!!!