4 ms·

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

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 12y ago
> This has been elevated to core functionality in GL4.
- fixermark 12y ago
  > 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 12y ago
    > 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.
- zanny 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        > "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.
wisienkas 12y ago
but java does fine with it needs of extensions to everything. How do you justify that?
- fixermark 12y ago
  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?
- scott_karana 12y ago
  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 12y ago
    I see what you mean. my bad

admax88q 12y ago

> This has been elevated to core functionality in GL4.

fixermark 12y ago
> 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 12y ago
  > 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.
zanny 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      > "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.

wisienkas 12y ago

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

fixermark 12y ago
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?
scott_karana 12y ago
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 12y ago
  I see what you mean. my bad