“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.
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
removed from core, but maybe existing further as extension (the same as in 1.?)
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)
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.
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).
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…
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…
No. When you resolve a multisampled framebuffer the size arguments to BlitFramebufferEXT are ignored.
But even if that wasn’t the case you wouldn’t get the individual sample colours.
OT anyway
The way I understand it is that the deprecation model states that new features do not need to specify interactions with deprecated features. Let’s say for example some kind of state object extension (which would be core later) is created; it will not need to handle interactions with all the deprecated features. This does simplify things quite a bit. Having read a few extension specifications, I can attest that much of their complexity is caused by interactions with the immediate mode.
This is incorrect. The size and position of the blit rectangle are definitely used. The restriction is that the source and dest sizes must match, i.e. you cannot downsample and rescale in a single operation. You can, however, downsample a subrect.
But you are right, BlitFramebuffer gives no access to individual samples. This restriction exists, in part, because the sample locations are undefined.
I think the deprecation model was the only sustainable way to evolve GL indefinitely. I see it as a way to amortize the pain of a complete rewrite over the course of some unspecified/indeterminate period of time.
Besides, a complete rewrite every few years or so would probably have been the same dog with different fleas.
they are interested in their consumers (enduser/ISVs). if the majority of them uses DX for games, that’s just fair. If the other majority uses OpenGL for serious applications and are “fine” with the state of tools (buying gdebugger… whatever) that’s just the way things run.
many seem to take this on almost religious level, as if they were lead wrong on purpose. (yeah LP yadda). But the situation with SDK, and “tool support” has been the same in OGL for years, and it’s a free world, ie on windows at least you have the choice.
as for the other OS, links have been presented before that Apple does have some OpenGL develop infos. And most linux developers are more the hacker, websearch of guys anyway not spoiled by company driven SDKs
Yeah. We don’t need no stinkin’ SDKs </mobster voice>
Back in reality… Does the SDK really matter that much at the professional level? Even if a college students started defecting in mass numbers to OGL, do you think the managers at EA and all the other big game companies would decide “Oh, we should switch to OGL”? I certainly don’t. At best, an SDK will entice indy developers and hobbyists, who may (And I have no statistics to back this up, it just makes sense to me) be targeting OGL already so they can get Linux and OSX support almost for free - for an indy developer, every possible eyeball counts.
I do think a free (or at least cheap) OpenGL debugger would be totally awesome. I doubt it will happen without a community push though (and between work, and several personal projects, I really don’t have time to pick up the mantle of making an OGL debugger). There is a free shader designer (not ShaderDesigner… I can’t think of it right now) That’s cross-platform. Really what’s missing is a debugger.
