[Xmas]

Originally Posted by willardjuice

But in reality, they just end up making a mess. Developers have to maintain a more complex code base (what if ihv x and y support extension w but ihv z doesn't? or what if ihv x, y, and z all implement extension w differently? what if it's changed again when it's officially added to the API?) for usually minor gains.

Depending on circumstances extensions may or may not be worth using, but having that option doesn't make your code more complex. On the other hand, if you really need a specific feature and have well-defined target platforms they can be very useful.

Extensions could work if somehow we could force all the relevant ihv's to agree on implementing the same feature in same manner in the same timeframe.

That's what iterations of the core API specification do. I'm not sure why you'd want extensions for that.

[willardjuice]

Depending on circumstances extensions may or may not be worth using, but having that option doesn't make your code more complex.

Of course I agree, my point though was merely that extensions are not some silver bullet that many believe it to be. They can add a lot of complexity for sometimes little gain.

On the other hand, if you really need a specific feature and have well-defined target platforms they can be very useful.

I suppose this is true. Extensions on a closed platform like iphone/ipad could work since you are only dealing with imgtec. But for the most part, developers have to deal with a lot more players than imgtec.

That's what iterations of the core API specification do. I'm not sure why you'd want extensions for that.

Shhh Xmas you're not supposed to say the punchline! As you might have guessed, I would prefer Khronos to release small updates (e.g. 4.3.x) instead of this extension system. I don't even care if these small updates only added extensions. It would make things much less complex while still providing quicker access to new extensions.

[Xmas]

Originally Posted by willardjuice

I suppose this is true. Extensions on a closed platform like iphone/ipad could work since you are only dealing with imgtec. But for the most part, developers have to deal with a lot more players than imgtec.

And when they do, those developers mostly stick to the lowest common denominator, which is the core API. Extensions are usually extensions because they don't represent the LCD for the time being (and might in fact never get there).

Shhh Xmas you're not supposed to say the punchline! As you might have guessed, I would prefer Khronos to release small updates (e.g. 4.3.x) instead of this extension system. I don't even care if these small updates only added extensions. It would make things much less complex while still providing quicker access to new extensions.

There have been seven updates since OpenGL 3.0 was released in July 2008. Do you think the update frequency is too low?

[willardjuice]

Originally Posted by Xmas

And when they do, those developers mostly stick to the lowest common denominator, which is the core API. Extensions are usually extensions because they don't represent the LCD for the time being (and might in fact never get there).

I agree, but remember what prompted this debate:

Originally Posted by Timothy Lottes

OpenGL 4.3 offers features beyond DX11.1 even on older non-DX11.1 hardware or OSes, thanks to a vendor extension mechanism. With extensions, developers get access to non-core hardware features if they want it, vendors can answer requests from developers for feature support they need, and the ARB has returned to the fast track of getting portable vendor features into the core API. This enables you as a developer to have your say in shaping the API and even the hardware itself. It is a cycle which enables innovation and rapid progress, where no single vendor has absolute control, so things are relatively fair for everyone involved: including consumers, hardware vendors, software vendors, and os vendors.

What Timothy Lottes claims is *technically* true, but in reality we all know it's not. The notion that ogl is ahead of d3d because of the extension system doesn't make sense. Developers, like you pointed out, often just stick with the core API.

And that's all I am claiming here. Extensions, for most cases, are meaningless. And to play them up like Timothy has done is borderline misleading. Certainly edge cases exist where they are useful, but let's not overstate their significance.

Originally Posted by Xmas

There have been seven updates since OpenGL 3.0 was released in July 2008. Do you think the update frequency is too low?

This is orthogonal to the discussion. My point was if OpenGL wishes to be an "agile" (fast changing) API, I would prefer it to do so through minor updates than an extension system. But for the record, I do believe they took a very long time to catch up to d3d.

[3dcgi]

Originally Posted by willardjuice

But for the record, I do believe they took a very long time to catch up to d3d.

That's an understatement.

[Ethatron]

I'm waiting for a partial resident texture API in D3D.

[Rodéric]

I'm waiting for a minimal yet complete API...

[Xmas]

Originally Posted by willardjuice

What Timothy Lottes claims is *technically* true, but in reality we all know it's not. The notion that ogl is ahead of d3d because of the extension system doesn't make sense. Developers, like you pointed out, often just stick with the core API.

I don't think that invalidates anything he wrote. It seems to me you're concentrating too much on the first sentence of that quote.

This is orthogonal to the discussion. My point was if OpenGL wishes to be an "agile" (fast changing) API, I would prefer it to do so through minor updates than an extension system.

But it's not an either/or choice. Extensions are still useful for exposing unique or experimental features as well as field testing before something goes into core.

[Rys]

Originally Posted by Rodéric

I'm waiting for a minimal yet complete API...

You'll be waiting until the heat death of the universe then as long as more than one IHV's hardware is being driven by the API, or the hardware has to support more than that API.

[willardjuice]

Originally Posted by Xmas

I don't think that invalidates anything he wrote. It seems to me you're concentrating too much on the first sentence of that quote.

I disagree here. I get the impression that he believe extensions are a benefit to everyone. That their main purpose is to make OpenGL more agile. Whereas I believe extensions are only useful in a small subset of situations and that, in reality, they do not make OpenGL any more agile. I also don't think extensions make OpenGL "fairer" as he claims.

For clarity: what do you consider the main benefit of extensions? And what do you think Timothy Lottes thinks is the main benefit of extensions?

Originally Posted by Xmas

But it's not an either/or choice. Extensions are still useful for exposing unique or experimental features as well as field testing before something goes into core.

I didn't mean to imply we should remove extensions. I just don't think they've ever been a good tool at making OpenGL more agile. If Khronos' aim is to allow OpenGL to change more rapidly than Direct3D, they would be better served to do it through small updates instead of relying on extensions.

[Ethatron]

You have to distinguish between the "ability to extend" and a "specific extension". You always say "extension(s) X(YZ) is bad" and in effect "extendibility is bad", which is not correct at all. Maybe you don't intend to say that ...

[willardjuice]

You have to distinguish between the "ability to extend" and a "specific extension". You always say "extension(s) X(YZ) is bad" and in effect "extendibility is bad", which is not correct at all. Maybe you don't intend to say that ...

No where did I say any of those things. What I'm saying is the current extension system in ogl isn't practical in most situations and we shouldn't treat it as this amazing selling point.

[Ethatron]

Here you say it. You're talking "extensions", not the mechanism to offer them:

Originally Posted by willardjuice

[...] I get the impression that he believe extensions are a benefit to everyone. That their main purpose is to make OpenGL more agile. Whereas I believe extensions are only useful in a small subset of situations and that, in reality, they do not make OpenGL any more agile.

[willardjuice]

Originally Posted by Ethatron

Here you say it. You're talking "extensions", not the mechanism to offer them:

But it should have been clear that I was referring to the extension system in OpenGL. This whole debate has been centered around OpenGL's extension system.

[Ethatron]

Okay ...

Originally Posted by willardjuice

[...] there are still people convinced that extensions are a great thing.[...]

(BTW: the extension which renders the teapot is the best piece of API you could ever get, one call, awesome results )

So it's not only that you think "extensions" are useless (because if there would be just a single worthy extension IYHO, then the mechanism to offer it must inherently be great), the entire extension mechanism is scrutinized and subsequently criticised by you.

Originally Posted by willardjuice

I get the impression that he believe [linethrough]extensions[/linethrough] the extension-mechanism is a benefit to everyone

Now, I understand not everyone likes teapot extensions, as such specific extensions produce specific opinions. Though I can't imagine what's the argument against the granted-and-standardized-ability-to-extend-opengl-at-your-discretion ...
Most people don't program at that a professional level, but this also allows you to write your own extensions, from some PoV this is even a greater thing than just consuming extensions.

[willardjuice]

I literally have no idea what you are talking about. I don't know why you think I'm against extensions in general (I'm not!). There are situations where the extension system in OpenGL can work well (e.g. closed systems), but for the most part they are unused. Thus when people say things like "OpenGL 4.3 offers features beyond DX11.1 even on older non-DX11.1 hardware or OSes, thanks to a vendor extension mechanism" or "It is a cycle which enables innovation and rapid progress, where no single vendor has absolute control, so things are relatively fair for everyone involved: including consumers, hardware vendors, software vendors, and os vendors" I can't help but to roll my eyes. They play such an insignificant part!!!

[Ethatron]

I think the wording in your posts fails to transport your real opinion then.

Originally Posted by willardjuice

I realize this is more of a personal preference thing [...], but never will extensions (in their current form) make sense to me.

[willardjuice]

Originally Posted by Ethatron

I think the wording in your posts fails to transport your real opinion then.

Okay this conversation has gone far enough. You're trolling at this point.

but never will extensions (in their current form) make sense to me.

[Ethatron]

Understood.

[Xmas]

Originally Posted by willardjuice

I disagree here. I get the impression that he believe extensions are a benefit to everyone. That their main purpose is to make OpenGL more agile. Whereas I believe extensions are only useful in a small subset of situations and that, in reality, they do not make OpenGL any more agile. I also don't think extensions make OpenGL "fairer" as he claims.

It may be true that a minority of developers directly benefits from using extensions, but like Timothy Lottes I believe that extensions have a substantial impact on shaping the API. Making a feature accessible to developers and essentially beta-testing it and its API is very useful for deciding what goes into the next core API update.

I didn't mean to imply we should remove extensions. I just don't think they've ever been a good tool at making OpenGL more agile. If Khronos' aim is to allow OpenGL to change more rapidly than Direct3D, they would be better served to do it through small updates instead of relying on extensions.

Again, I don't think there's an "instead" here. But core API updates only make sense when you have an agreed upon and tested set of new features, however large or small, and that's where the "extension first, core later" model helps.

[Silent_Buddha]

Originally Posted by Xmas

Again, I don't think there's an "instead" here. But core API updates only make sense when you have an agreed upon and tested set of new features, however large or small, and that's where the "extension first, core later" model helps.

And yet, despite that DirectX has been more nimble and far faster to innovate and implement than OGL has. Due almost directly to Microsoft's ability to talk to the various IHVs not only to determine where they think the technology is going, how possible it is to implement, and how long it will be to implement; but as well to talk to software developers to find out where they think the technology is going, what they wish to see in the near and far future, and what priority they place on things.

Their ability to work with both sides of the aisle (hardware and software) in order to come up with a coherent and standard set of features (that is both possible to implement on the hardware side and desirable by developers on the software side) and to enforce those has allowed for far more rapid developement in the 3D space than OGL has. NOTE - this isn't to say that the extension system in OGL hasn't lead to some interesting innovations.

The closest thing to the extension system in D3D was caps, but those were unpopular with software developers and lead to product confusion with consumers and hence MS tried to drop them in Dx10 and Dx11. Only, apparently to see them possibly make a reappearance in Dx11.1 (likely at the behest of one IHV or another but not at the request of software devs). I have a feeling they will remain just as unpopular. Basically extensions mostly benefit the hardware vendors. Might benefit a "few" software vendors. And is mostly a mess for your end consumer (do they have the right hardware? did they buy from the right IHV? does their OGL level X card support some esoteric extension only available on one card from one vendor? Etc.).

Regards,
SB

[darkblu]

Originally Posted by willardjuice

I didn't mean to imply we should remove extensions. I just don't think they've ever been a good tool at making OpenGL more agile. If Khronos' aim is to allow OpenGL to change more rapidly than Direct3D, they would be better served to do it through small updates instead of relying on extensions.

Extensions don't substitute core functionality, they are fundamentally a transport for what gets into the core. As such, they are indispensable for the standard. As a 'side-effect', extensions also allow vendors to properly expose their hw to developers when needed - think embedded development.

[Xmas]

Originally Posted by Silent_Buddha

And yet, despite that DirectX has been more nimble and far faster to innovate and implement than OGL has. Due almost directly to Microsoft's ability to talk to the various IHVs not only to determine where they think the technology is going, how possible it is to implement, and how long it will be to implement; but as well to talk to software developers to find out where they think the technology is going, what they wish to see in the near and far future, and what priority they place on things.

Their ability to work with both sides of the aisle (hardware and software) in order to come up with a coherent and standard set of features (that is both possible to implement on the hardware side and desirable by developers on the software side) and to enforce those has allowed for far more rapid developement in the 3D space than OGL has.

OpenGL has been lagging behind for a while, but I doubt that has anything to do with extensions. Unlike Microsoft Khronos essentially is the sum of its members, so it simply can't operate the way Microsoft does. Though you'd be mistaken to think that OpenGL does not take in voices from both sides of the aisle.

The closest thing to the extension system in D3D was caps, but those were unpopular with software developers and lead to product confusion with consumers and hence MS tried to drop them in Dx10 and Dx11. Only, apparently to see them possibly make a reappearance in Dx11.1 (likely at the behest of one IHV or another but not at the request of software devs). I have a feeling they will remain just as unpopular. Basically extensions mostly benefit the hardware vendors. Might benefit a "few" software vendors. And is mostly a mess for your end consumer (do they have the right hardware? did they buy from the right IHV? does their OGL level X card support some esoteric extension only available on one card from one vendor? Etc.).

Unless you absolutely require an extension feature (which only makes sense in very specific circumstances) I'm not sure that consumers would have to care about that kind of low-level information.
Caps blur the line between core and optional feature sets. With extensions that line is quite clear.

[rpg.314]

Direct state access has been an extension for years now. Why isn't it in core yet, when every dev likes it?

[Andrew Lauritzen]

I have to agree that I think OpenGL - while slowing improving - has been in a unique position to actually change up the landscape of rendering APIs by doing truly forward-looking stuff like moving to explicit command buffer creation, dependencies, etc. But yet they seem to content to just follow DX (almost exactly), which is kind of sad at this point. And with all of their adding checkbox features, they still haven't addressed some of the basic problems in the API (direct state access is a good example, but I want to see far more than just that done)!

But that said, the reality is that the core concept of GL (design by democracy) has just proven far less effective than DX's "benevolent dictator" model. In the GL space there is no one that can really force people to standardize on hardware and features and quite frankly, that's why they end up following as well: because they can count on the features in DX being available on all GPUs as that is the primary design target.

Secondarily but not less important is the fact that no one writes good software infrastructure around GL and drivers. The Khronos conformance tests are a joke in terms of actually testing the entire API (including failure mode testing), which directly impacts driver quality. I shouldn't harp on GL too much here though as CL is 100x worse.

Regarding extensions, it's nice in theory that they exist formally in GL but it doesn't really matter much in practice. GL itself is already dicey enough that you can't really trust it to be fully portable (due not really knowing if you've inadvertently relied on a non-standard feature that just "happens to work" on one implementation), and once you add extensions you might as well be programming directly to a card's command buffer format.

Extensions are a proof of concept to allow key stakeholders to fool around with and then pressure the relevant standards, but none of these uses require a public mechanism like GL has. And let's not forget that all of the big GPU vendors have "unofficial" DX extension APIs as well that actually get used in games, unlike a lot of GL extensions.