[fixermark]

Every time I read the words "The extension," I cringe a little. In my experience, "There's an OpenGL extension for it" translates almost directly to "This will not work on a critical percentage of your customer's machines, and will work in a way that violates the extension's documentation in another critical percentage."

If key parts of the API that you need live in "the extensions," then the API itself is not a properly-tuned abstraction to serve your needs well.

[admax88q]

> This has been elevated to core functionality in GL4.

[zanny]

Which many systems still do not support. You don't even need to get mad at drivers, there is plenty of graphics hardware (the latest being the Intel Sandy Bridge GPUs from three years ago) that only supported up to 3.3. And even if you say "well, if you don't have a tessellation capable GPU, get a new one" there is still the problem of the Linux drivers being at 3.3 right now, and older versions of OSX only supporting 2.1.

Hell, the pre-Sandy Bridge Intel hardware only supports 2.1. It is only in the last 5 years that both mainstream GPU manufacturers supported 4 at all too, I have a GTX 285 that can't do tessellation either.

[admax88q]

Sure implementations are still playing catchup, but you can't mark that as a failing of the standard.

The standard addressed the concern and now its up to implementors to do it.

[fixermark]

But as the original article notes (in a bit of a roundabout way), OpenGL-the-standard vs. OpenGL-the-ecosystem is a bit of an empty debate. Unless you're one of the privileged few who only writes OpenGL code that targets one hardware platform... It doesn't much matter what the standard says if my customers don't install hardware that can take advantage of the new standardized features, if they never upgrade their graphics drivers for their older hardware, if the driver vendors never bother to update the old drivers to meet newer versions of the standard that their hardware could support but is no longer in their financial interests to support, etc., etc., etc.

"OpenGL is broken" refers to the market adoption of the standard, because when you're developing graphics software for consumers that's the aspect you care about.

[fzltrp]

> "OpenGL is broken" refers to the market adoption of the standard, because when you're developing graphics software for consumers that's the aspect you care about.

(This isn't the only point the OP is arguing about, but anyway.) What exactly would be the alternative? It's either there's a standard, and adherents must follow its core features to get the compliancy stamp, or there are no standards, and each go its merry way, up to third parties to follow up on all the completely different API resulting from that. As someone else said, there are core levels in the standard, which give garantees to third parties. It hasn't always been like that, but now we do have them.

As for support of the latest features on my old Geforce 7600, I guess I should accept the fact that they cannot be implemented efficiently, and if I want to play the latest installment of Wolfenstein, I'll have to grab a new card. Or I could try getting a more modest game. There is clearly a commercial aspect to this whole upgrade mechanism too, but since upgrades are necessary for technical reasons, it's difficult to argue against the mercantile part.

[fixermark]

> It's either there's a standard... or there are no standards, and each go its merry way

In my experience, OpenGL walks the middle line. There is certainly a core set of functions that (almost always, discounting buggy drivers) work. But the core set doesn't span all the critical functions you need for what modern game players would consider a performant game engine (such as hardware synchronization to eliminate "tearing"). So game engines will need to factor in the GL extensions, which put us in the "up to third parties to follow up" world. It's a frustrating environment to work in; you can't really ever trust that your code will either succeed or fail on any given hardware configuration, and you're stuck playing whack-a-mole on bug reports that you lack the hardware to reproduce.

> As for support of the latest features on my old Geforce 7600, I guess I should accept the fact that they cannot be implemented efficiently

I wish it were that simple. That, I could deal with.

I've worked with a card that had a bug in the GLSL compiler. A particular sum simply wasn't compiled, and we had to work around the problem by multiplying by 1.000000000000000001 to force the compiler to generate the bytecode for the whole calculation (the fact this trick works is something one of our veteran engineers "just knew would work," so we got lucky). There is functionally no chance of that software bug ever getting patched; card vendors don't care about older versions of their technology, and even if a driver version were out there that patched the bug, you can't trust machine owners to keep their drivers up-to-date.

More frustratingly, as I mentioned elsewhere, I've worked with cards that implement things that should be high-performance (like stages of the shader pipeline) in software, just to claim they have the capability. Since OpenGL gives you no way in the API to query whether a feature is implemented in a reasonably-performant way, you either do some clever tricks to suss this stuff out (F.E.A.R. has a test mode where it runs a camera through a scene in the game and quietly tunes graphics pipeline features based upon actual framerate) or gather bug reports, blacklist certain card configurations, and keep going.

Old cards not being as powerful as good cards I can deal with; if we could simply say "Your card must be X or better to play," we'd be fine. New cards with bugs and under-performant cards that lie about their performance to clear some market hurdles are the maddening corners of the ecosystem.

[fixermark]

> The unit issue has not been resolved however, but nvidia did propose a DSA extension, which so far wasn't taken up by any other vendor.

... which is graphic-developer-ese for "I hope you like branching your render engine some more."

[admax88q]

> Suffice to say, most hardware does not support DSA, and underneath, it's all texture units, even in Direct3D, so railing against texture units is a complete red herring.

[wisienkas]

but java does fine with it needs of extensions to everything. How do you justify that?

[scott_karana]

Java is actually cross-platform. OpenGL is just an API.

OpenGL extensions are typically optional parts of the spec, available on a per-implementation basis, and are not pluggable: you're at the mercy of the vendors, assuming your target audience even has up-to-date drivers at all.

Compare the following:

  Java class works on JVM on Windows, Linux, OS X...

vs

  OpenGL implementation for Intel HDs on Windows
  OpenGL for Radeons on Windows
  OpenGL for Geforces on Windows
  OpenGL for Intel HD on OS X
  OpenGL for Radeon on OS X
  OpenGL for Geforce on OS X

Now add Linux and various API-levels of Android to the mix and cry if any single one of these permutations is missing the extension you want.

[wisienkas]

I see what you mean. my bad

[fixermark]

I don't develop in Java (outside of Android); I'm afraid I'd need you to clarify what you mean to answer the question. Are you referring to JNI?