The ARB announced OpenGL 3.0 and GLSL 1.30 today

[ebray99]

"plus a couple more?" I could understand the assumption that the extensions on the slides would see widespread implementation, but where do you get the "couple more" from?

The couple more I'm referring to were simply mentioned during the BOF presentation and not on the slides.

As for being intentionally misled, isn't that just par for the course with the ARB, who've been doing it for the last 9 months?

I personally don't feel like I was misled at all during the whole GL3 thing. I think they failed to communicate effectively with the community, and I think most of this backlash is a result of their prolonged silence. Basically, they didn't mislead anyone; they just didn't lead anyone anywhere. That said, I don't think the API itself is a failure in any way. Their PR on the other hand could use a little work.

Kevin B

[Brolingstanz]

And as was pointed out in the slides, the main obstacle to GL's evolution in recent years has been the difficulty in layering new functionality on top of an aging API, a difficulty which has now been put to pasture, thanks to the new deprecation model.

Onward HO! Mush! Muuuush! *indistinct barking and whipping*

[skynet]

Lifecycle of a feature:
1. become an extension
2. become core feature
3. become deprecated, but still be in core
4. removed from core, but maybe existing further as extension (the same as in 1.?)
5. finally die out

The single steps are not bound to a particular version in the API. Now imagine N features with overlapping, 'phase-shifted' lifecycles... must be a nightmare to manage.

the main obstacle to GL's evolution in recent years has been the difficulty in layering new functionality on top of an aging API,

Not being a native speaker, I'm a bit unsure how to interpret "put to pasture". But I really want to know why NV and ATI didn't revolte more against the current API and say "enough! we better start over with a clean sheet of paper."

Revolution through 3volution!
(one might think, it took the last 8 months to invent that motto)

[Brolingstanz]

[A race horse is "put to pasture" when it can no longer compete (cf. retired).]

[Leadwerks]

Deprecated = Khronos intends to do something about it, someday. We already knew what features were "deprecated". Saying you intend to do something is not the same as doing it.

In any case, the entire problem all along has been AMD's and Intel's drivers. I am very skeptical about their ability to produce working drivers, since OpenGL "3" does not make that task any simpler.

[Ilian Dinev]

First off, how many of you that are bitching about GL, actually program in DX also?

Second, how many actually tried profiling the performance difference between a properly programmed GL version of the same engine and a properly programmed DX9 or DX10 version on good drivers (ie the newest ones from NVidia)?

A commercial app of mine runs faster and smoother under OpenGL. Some research on instancing also fared better. I just love the separate FIFOs and ARB shaders (compiled via Cg).

[Auto]

no, custom resolves are not supported currently. custom resolves mean that you can access all subsamples in a shader and do the downsampling yourself after for example tone mapping etc.

That's slightly confusing as the EXT_framebuffer_multisample
spec states:

"...the application explicitly controls when the
resolve operation is performed. The resolve operation is affected
by calling BlitFramebufferEXT (provided by the EXT_framebuffer_blit
extension) where the source is a multisample application-created
framebuffer object and the destination is a single-sample
framebuffer object (either application-created or window-system
provided)...
"

Is this not the same? It would seem this is the kind of exposure I'm looking for...

[Xmas]

Is this not the same?

No, because you only control when the resolve operation is performed, not how.

[bobvodka]

no, that just forces the resolve to a non-AA'd texture/render target like a normal texture.

What Chris Lux is talking about is being able to access the AA'd texture directly and the subsamples of it.

[Auto]

Ah... so is it that you can't actually read an msaa fbo as a texture then?

[Edit]

Having just done some RTFM-ing of the extension spec:

"(3) Is ReadPixels (or CopyPixels or CopyTexImage) permitted when
bound to a multisample framebuffer object?

RESOLVED, no

Resolved by consensus, prior to May 9, 2005

No, those operations will produce INVALID_OPERATION. To read
the contents of a multisample framebuffer, it must first be
"downsampled" into a non-multisample destination, then read
from there. For downsample, see EXT_framebuffer_blit.
"

Hence I presume this answers my question...

So to roll your own resolve with this method (that is, hack), would it be possible to do a framebuffer blit to a non-msaa rendertarget with nearest filtering, but say, with the target fbo resolution the same size as the msaa target (ie: 4x) to minimize the downsampling effect. Then do your post, and your own shader resolve after? May be a bit dodgy but possibly the closest thing to a custom resolve...