OpenGL 4.3 (with compute shaders!)

[3dcgi]

An API that's stagnant requires developers to use extensions and have a messy code base, but if an extension is truly useful it should show up in competing hardware about two years later. Since game development times are so long this means most games won't ship until a lot of hardware supports the feature. The problem comes when the API isn't updated frequently enough to pickup useful features.

It's hard to force IHVs to implement features in the same time frame and this removes a benefit of innovation by being first. It takes a gorilla like Microsoft to drag companies in a direction they wouldn't otherwise go.

 

[Ethatron]

Extension-capability also gives a HV to express a different opinion than either the standard-body or a API-owner, and that is a good thing. Besides supporting true evolution (instead of planning) it allows a HV to play it's strengths in a context of it's choosing. I don't know if it exists, but nVidia could for example provide OGL-CUDA interfaces via extensions, formally and well defined. As much as I respect the work of ATI in hacking up the DX9-API ("extending" it), it shouldn't be necessary to do it that way. Extendability is better.

 

[MJP]

Because you hear the same thing over and over. "Extensions are great! Now developers and end users don't have to wait for all the red tape! Everyone wins!"

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. Things are even worse in the embedded market. 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.

I'd much prefer D3D10+'s all or nothing approach. I can perform essentially one check and immediately know what the card is or is not capable of. I realize this is more of a personal preference thing (and my initial post was probably a bit too strong), but never will extensions (in their current form) make sense to me.

Yeah I really have to agree regarding extensions. Don't get me wrong, I love making use of every feature available in the hardware, but only if there's enough user base for that particular hardware. For consoles it's almost a no-brainer: you know there will be millions of that hardware configuration in the wild, so it makes sense to add code paths that exploit its unique features. But if an IHV adds extension X that's only supported on GPU family Y and above...well that's less obvious to me. In fact it seems like in such cases the only party that stands to gain much is the IHV, and so I won't be very convinced by their urgings to use their super-awesome extension.

I really feel that the feature levels system is one of the best things that ever happened to D3D, since they let you easily partition your target hardware into large groups with a corresponding set of functionality. I'm actually pretty upset that they added some new caps for D3D11.1.

 

[homerdog]

Extension-capability also gives a HV to express a different opinion than either the standard-body or a API-owner, and that is a good thing. Besides supporting true evolution (instead of planning) it allows a HV to play it's strengths in a context of it's choosing. I don't know if it exists, but nVidia could for example provide OGL-CUDA interfaces via extensions, formally and well defined. As much as I respect the work of ATI in hacking up the DX9-API ("extending" it), it shouldn't be necessary to do it that way. Extendability is better.

Extendability is great, but I'm not sure how you could logically argue against willardjuice here. It will never be practical for a developer to optimize its engine around extensions that only a small fraction of available hardware can support.

 

[Ethatron]

Once your in control of the target-hardware it is practical. Once the target hardware doesn't change for a while it is even a necessity to take advantage of all the unique capability.
I'm not arguing against willardjuice, I just remind you of the chance which is in extensions, and honestly as a developer I never bothered to have choice and exotic stuff if I wanted to, and I haven't been forced to support them all at point blank yet. I think it's a constructed argument which has no bearing in reality.
Code is an organic thing, it changes all the time, and API-changes are really very minor. Is deferred-shading now bad-bad-bad because I have to rewrite the whole core? Damn, they shouldn't have invented it.
The principle that extensibility is good per-se isn't invalidated by that a developer thinks a specific extension is a waste of time (of IHV resources). Wasting time on lamenting it, is the developer's problem.

 

[Xmas]

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]

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]

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:

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.

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]

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

That's an understatement. :smile:

 

[Ethatron]

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

 

[Rodéric]

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

 

[Xmas]

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]

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]

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?

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:

[...] 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]

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 ...

[...] 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.

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.