6 ms·

OpenGL Is Broken

156 points by watermel0n 12y ago

feistyio 12y ago
As is your server.
maaku 12y ago
You're webserver is broken. Anyone have a cached link?
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- wlesieutre 12y ago
  http://webcache.googleusercontent.com/search?q=cache:oKkIlJG5tAoJ:www.joshbarczak.com/blog/%3Fp%3D154+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:oKkIlJG...
- robin_reala 12y ago
  https://webcache.googleusercontent.com/search?q=cache:http%3A%2F%2Fwww.joshbarczak.com%2Fblog%2F%3Fp%3D154 https://webcache.googleusercontent.com/search?q=cache:http%3... !cache in DDG will get that for you in future.
pyalot2 12y ago
This post is factually wrong, and misguided. Here's why: #Preamble: Except on Windows you cannot run Direct3D anywhere else. Unless you plan not to publish on Android, iOS, OSX, Linux, Steambox, PS4 etc. you will have to target OpenGL, no matter how much you dislike it. #1: Yes the lowest common denominator issue is annoying. However, in some cases you can make use of varying features by implementing different renderpaths, and in other cases it doesn't matter much. But factually wrong is that there would be something like a "restricted subset of GL4". Such a thing does not exist. You either have GL4 core with all its features, or you don't. Perhaps author means that GL4 isn't available everywhere, and they have to fall back to GL3? #2: Yes driver quality for OpenGL is bad. It is getting better though, and I'd suggest rather than complaining about OpenGL, how about you complain about Microsoft, Dell, HP, Nvidia, AMD etc.? #compiler in the driver: Factually this conclusion is completely backwards. First of all the syntactic compile overhead isn't what makes compilation slow necessairly. GCC can compile dozens of megabytes of C source code in a very short time (<10ms). Drivers may not implement their lexers etc. quite well, but that's not the failing of the specification. Secondly, Direct3D is also moving away from its intermediary bytecode compile target, and is favoring delivery of HLSL source code more. #Threading: As author mentions himself, DX11 didn't manage to solve this issue. In fact, the issue isn't with OpenGL at all. It's in the nature of GPUs and how drivers talk to them. Again author seems to be railing against the wrong machine. #Sampler state: Again factually wrong information. This extension http://www.opengl.org/registry/specs/ARB/sampler_objects.txt http://www.opengl.org/registry/specs/ARB/sampler_objects.txt allows to decouple texture state from sampler state. This has been elevated to core functionality in GL4. 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. 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. #Many ways to do the same thing: Again many factual errors. Most of the "many ways" that author is railing against are legacy functions, that are not available in core profile. It's considered extremely bad taste to run a compatibility (to earlier versions) profile and mix&mash various strata of APIs together. That'd be a bit like using Direct3D 8 and 11 functionality in the same program. Author seems to basically fail in setting up his GL context cleanly, or doesn't even know what "core profile" means. #Remainder: Lots of handwaving about various vaguely defined things and objecting to condjmp in the driver, again, author seems to be railing against the wrong machine. Conclusion: Around 90% of the article is garbage. But sure, OpenGL isn't perfect, and it's got its warts, like everything, and it should be improved. But how about you get the facts right next time?
- leorocky 12y ago
  > how about you complain about Microsoft, Dell, HP, Nvidia, AMD etc.? These companies are businesses that need a business reason to support your platform. Until more people are playing triple A games on platforms that use OpenGL you can't really fault them for spending money when it doesn't make sense. Apple designs its own chips for its mobile device so I'd think the OpenGL on iOS would have better driver support.
  - pyalot2 12y ago
    OpenGL is the only thing you get on iOS. There is no Direct3D on iOS. Likewise, it's the only thing you get on PS4, Steambox, OSX etc. But that's not my issue, I acknowledge freely that OpenGL drivers are bad. I just don't quite see how that's a failing of OpenGL, rather than the vendors who actually implement the drivers.
    - cwyers 12y ago
      Well, no, Sony has its own low-level API that you can use on the PS4[0], and because all PS4s use the same GPU you don't have to worry about a lot of what OpenGL has to offer you in terms of abstracting away the underlying hardware, if all you care about is the PS4. http://arstechnica.com/gaming/2013/03/sony-dives-deep-into-the-ps4s-hardware-power-controller-features-at-gdc/ http://arstechnica.com/gaming/2013/03/sony-dives-deep-into-t...
    - fixermark 12y ago
      The bigger problem is a failing of the ecosystem at large; there's an insufficiently toothful agency policing the vendors and a lack of gold-seal certification that matters, leaving space for vendors to do whatever gets the card out the door before the competition. OpenGL's breadth as an API definitely doesn't help ("now that you've implemented direct-buffer rendering, let's go implement all that glVertex crap that lets you do the exact same thing, only slower! Your library coders have infinite time, right?"). But I doubt it's the root cause of the frustration; the "hit the benchmarks and beat ATI out the door this Christmas" ecosystem is my biggest gripe. I've had to deal with cards that explicitly lie to the software about the capabilities by specifying they support a shader feature that's implemented in software without acceleration (!!!). There's no way to tell via the software that the driver is emulating the feature besides enabling it and noticing your engine now performs in the seconds-per-frame range. So we blacklist the card from that feature set and move on, because that's what you do when you're a game engine developer.
fixermark 12y ago
Quite a few of these issues (especially in the "Too many ways to do the same thing" category) relate to OpenGL's age as an API, which is something Direct3D's design was able to learn from and improve upon. OpenGL's origin was as a vector-based drawing tool for CAD applications which was repurposed to games; D3D was targeted for performant rendering with games as a specific target. This is demonstrated by some key features necessary for performant games (clock synchronization to avoid 'tearing' comes immediately to mind) that are core to the D3D spec and extensions to the OpenGL spec. There's also a bit of a cultural issue; if you learn OpenGL from the 'red book,' you'll learn the function-per-primitive API first, which is precisely the wrong tool for the job in making a performant game. Really, the OpenGL API is almost multiple APIs these days; if you're using one flow of how to render your primitives, the other flow is downright toxic to your rendering engine (in that it's going to muck about with your GL state in ways that you shouldn't burn mental energy predicting). Some of this is ameliorated by the OpenGL ES standard, which throws away a big chunk of the redundancy. But I'm not yet convinced that OpenGL has gotten away from its philosophical roots as a performance-secondary CAD API, which continues to dog its efforts to grow to serve game development needs. The fact that it's functionally the only choice for 3D rendering on non-Windows platforms is more testament to the nature of the hardware-software ecosystem of graphics accelerators (and the creative doggedness of game developers) than the merits of the language.
- Aardwolf 12y ago
  It would be interesting if they made a high-performance variant of the red book using the latest standard, e.g. the "bright red" book or "crimson book" or so :)
  - fdr_cs 12y ago
    Both 5th and 6th editions of OpenGL Superbible use only Core Profile functionality. It's the best way to start OpenGL nowadays
  - TuringTest 12y ago
    Something like this? http://www.arcsynthesis.org/gltut/ http://www.arcsynthesis.org/gltut/
foxhill 12y ago
theory: articles of the form: "X is broken", "X is wrong", or some other equally dramatic statement, say almost exactly the same thing; nothing.
- sdfjkl 12y ago
  While I hate link baiting as much as the next guy, I find myself agreeing with most of the things he says about OpenGL.
  - foxhill 12y ago
    if perhaps he suggested how one might change things to make it better, then maybe his arguments would have merit. right now, all this is, is a list of his personal complaints of the API. and hence, it's aimed at the users of OpenGL. i.e, we're already aware of the crap that's in the standard. this is not news to us. upvoting and supporting this sort of article is a bee's dick away from a programmers circle-jerk. > there are languages that people hate, then there are languages that do not get used. replace language with API.
  - cheery 12y ago
    Too bad there's no alternatives.
- deluvas 12y ago
  Too bad you're getting downvoted, because it's true.
foxhill 12y ago
if perhaps he suggested how one might change things to make it better, then maybe his arguments would have merit. right now, all this is, is a list of his personal complaints of the API. and hence, it's aimed at the users of OpenGL. i.e, we're already aware of the crap that's in the standard. this is not news to us. upvoting and supporting this sort of article is a hairs width away from a programmers circle-jerk. > there are languages that people hate, then there are languages that do not get used. replace language with API. edit: so, my comments are dead. i wasn't aware dissent was so strongly discouraged.
anotherfadjs 12y ago
You can use pre-compiled binary GLSL objects during development with ARB_get_program_binary. And yes OpenGL is broken and painful, live with it.
CmonDev 12y ago
And it will never be properly fixed due to backwards-compatibility requirements - just hack-patched. Just like web (HTML/CSS/JS).
druidsbane 12y ago
Well-reasoned response: http://timothylottes.blogspot.com/2014/05/re-joshua-barczaks-opengl-is-broken.html http://timothylottes.blogspot.com/2014/05/re-joshua-barczaks...
- mmarks 12y ago
  I nod my head in agreement with most of these OpenGL are broken articles. I've work on the OpenGL version of Call of Duty, Civilization, and more for the Mac. I think Timothy misses the real point on driver quality. https://medium.com/@michael_marks/opengl-for-real-world-games-7d0f4d35891c https://medium.com/@michael_marks/opengl-for-real-world-game...
Mikeb85 12y ago
So the solution he proposes at the end is to use Mantle? AMD has already proven themselves incompetent (or are they only unwilling?) at implementing OpenGL, unable to compete with either Intel or Nvidia, and now they want to fragment graphics APIs? And this is the 'solution'? As for OpenGL's issues - that's what happens when a spec gets old enough. But the fact remains, it's the only graphics API that could be called 'universal', they have modernized the spec, and despite all its failings, somehow it still delivers better performance than DirectX...
alariccole 12y ago
Your site is broken. http://webcache.googleusercontent.com/search?q=cache:http://www.joshbarczak.com/blog/?p=154 http://webcache.googleusercontent.com/search?q=cache:http://...
shmerl 12y ago
What is the current stance of Nvidia and Intel on implementing Mantle support? And what are the chances of mobile GPU makers doing the same? Is it easier to make a better OpenGL 5, or to adopt Mantle across all GPU manufacturers?
- corysama 12y ago
  Even if it is technically quite feasible, I would be seriously surprised if Nvidia and Intel implement Mantle if only for political reasons. However, they definitely will implement DX12 --which as far as I can tell is pretty much the same thing as Mantle except explicitly multi-vendor. If Mantle was a tap on OGL's door, DX12 is a full-on wake-up call. Back when I worked in Windows/console games, my market demanded D3D (+ sony/nintendo's wacky custom APIs). Now I work in mobile and my customers demand GLES. GL advocates used to cry "GL has the better tech! D3D only wins because of politics! Boo!" It will be quite a turn if they switch tunes to "D3D has better tech, but GL still wins because of politics! Yay!" DX12 API Preview vid http://channel9.msdn.com/Events/Build/2014/3-564 http://channel9.msdn.com/Events/Build/2014/3-564 DX12 API Preview slides http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fvideo.ch9.ms%2fsessions%2fbuild%2f2014%2f3-564.pptx http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%...
  - shmerl 12y ago
    DX12 is not the way forward because it remeains MS only and there is no indication that MS is interested in opening it up. The way forward is either creating a new open API which all manufacturers would support (Mantle, or whatever), or seriously improving OpenGL if it's possible.
  - Tmmrn 12y ago
    > It will be quite a turn if they switch tunes to "D3D has better tech, but GL still wins because of politics! Yay!" What are you actually comparing? Yet to be released DirectX12 v.s. OpenGL 4.4? Or v.s. what will actually "compete" against it, once it is actually released and used, OpenGL 4.5 or 5.0? Are you just assuming future versions will be worse than Direct3D? "used to cry"? That sounds all very fair and objective.
raverbashing 12y ago
I think what's broken is not OpenGL, D3D, etc What's broken is that the abstraction between graphics card and data (on the screen) is too big We don't have troublesome/fat drivers as these since the "Softmodem" days and even then (Wifi is also complicated) It's too big of a gap. In 2D graphics, you send graphical data and it is displayed. You may even write it directly to memory after some setup. Audio, same thing. Network, it's bytes to the wire. Disk drive, "write these bytes to sector X" (yes, it's more complicated then that, still) With 3D, we have two APIs that have an awful amount of work to do between the getting the data and displaying it. I'll profess my ignorance in the low-level aspects, I only know "GlTriangle" , OpenGL 101 kind of stuff, and I have no idea how: 1 - this is sent to the videocard, 2 - how does it decide to turn that into what we see on the screen. Compared to the other drivers this is a lot of work and a lot of possibilities of getting this wrong. Adding GPGPU stuff makes it easier in one aspect and more complicated in other aspects. We don't have a generic way of producing equal results from equal inputs (not even the same programming environment is available) We don't have OpenGL, we have "this OpenGL works on nVidia, this other one works on ATI, this one works on iOS, or sometimes it doesn't work anywhere even though it might be officially allowed"
- zanny 12y ago
  > We don't have OpenGL, we have "this OpenGL works on nVidia, this other one works on ATI, this one works on iOS, or sometimes it doesn't work anywhere even though it might be officially allowed" But this is just the shortfall failure to be standards compliant. We have multiple ARM implementations in CPU space, we have two vendors x86 CPUs, we have all kinds of wireless cards, but assembly on one ARM core better run on another, your x86 binary better run on ARM or Intel chips unless you use vendor specific extensions, and your wireless radio better process inbound data properly regardless of the sender. I think the real problem is that in the massively parallel pipeline architecture space (aka, gpus, but they are more than just graphics processors anymore) is that they aren't treated like proper programmable computers. What we should have are compilers to build ASM binaries for each architecture, and sane ISAs. That would mean in the present tense you would need Intel: preSB, SB, IVB, Haswell, Broadwell, Skylake, etc compilers. I've never read their ISA documentation, so I don't know which of these have common core so that you could treat it like a CPU - ie, base instruction set with extensions like SSE or NEON. I do imagine though if we weren't working at such an absurdly high level, we would see graphics hardware conform to the same model as CPUs - common ISA, with multiple implementations. I guess the problem there is that the way all modern ISAs are handled is ridiculous and stupid. Intel "owns" x86, ARM "owns" itself, etc. The reason we don't have reasonable CPU competition is that you don't just compete in hardware implementation, you either need to pay extortion to use what is effectively the same API - the same ISA - and that is one of the strengths of the graphics industry. The effective ISA that software is built against is predominantly open (most GPU code is openGL, despite how many directX games there are). We can see the difference - very little hardware runs DirectX because they have to pay MS the privilege to support it, and then it isn't even a standard at all so you can't use it on anything but Windows. It is congruent with proprietary ISAs for cpus. An example of a non-proprietary ISA is SPARC. I've never really looked into how good an ISA it actually is, but it is royalty free unless you want to use the branding - you can implement your own SPARC cpus without paying jack, the way it should be. So like I said, what we really need is a common open ISA for hardware graphics accelerators to implement, and then independently develop extensions for that can be proposed and adopted into the mainstream standard. And if that standard ever becomes overly bloated, any vendor can develop their own newer base to handle newer paradigms or fix bloat, the same way we see programming languages go. If I didn't have to figure out how to eat or didn't have another dozen things I'd want to do, I'd definitely want to see what I could manage writing a binary compiler for the SI ISA from AMD and seeing how performant you could make some other high level graphics language with compiled binaries. That is kind of what they did with Mantle, but their continued showing of not making any effort to open that language up to standardization or even just publishing it at all shows that it certainly won't be the answer.
espadrine 12y ago
The "compiler in the driver" part of this post sounds awfully like the "asm.js vs. NaCl" debate. Sure, building an IR from scratch is fun. But making it truly cross-platform and ready for many usages is really hard. Also, the GLSL source is an IR between the programmer's intent and the driver's behaviour. Code is just another type of binary. It is just slightly harder to parse, but not by much; without performance comparisons, a complaint about how hard it is to parse code is invalid. Feeding the driver GLSL can also yield much clearer error messages for programmers. I can only imagine what kinds of error messages the IR compiler would produce. Sure, hopefully, our cross-platform IR would be accepted by all GPUs without pain, but that's improbable. Regardless, starting from a clean slate is much harder than working our way from the current state to an improved OpenGL. Just like few browsers are on board with NaCl, few GPU makers would be on board with a brand new design.
- fzltrp 12y ago
  > Sure, building an IR from scratch is fun. But making it truly cross-platform and ready for many usages is really hard. It's not that hard, as long it remains as close as possible to the source language (ie. GLSL). Iow, as the OP is advocating for, an AST of the shaders. This removes the cost of parsing the source code (but requires on the other hand to validate the AST, so this isn't exactly a complete gain, but definitely an progress compilation wise). However, I suppose that what motivated the choice of using GLSL source directly is the simplicity of the approach: no need to build the GLSL scripts separately. When working with interactive tools, it's a non negligible comfort, imho. Another interesting aspect is the ability to build the scripts dynamically, like people do with SQL. I wonder if this approach is used by professional game studios.
AshleysBrain 12y ago
I think the difficult thing about OpenGL is it is hard to learn. The core profile of the latest version might be nice, but in practice there are still a wide range of OpenGL versions in use, so you have to learn the various ways of doing things through the OpenGL versions, or code against a crufty old version which is the lowest common denominator. Then there are various driver issues, platform-specifics around context creation, and so on. Overall it's a pretty tough chestnut if you're not going to use it directly instead of relying on an engine/framework that has figured out lots of that already. Mobile on the other hand seems decent - OpenGL ES 2+ seems to be a well-designed clean and relatively minimal API with widespread support.
Cocodyne1 12y ago
OpenGL works fine for me, so it must be user/programmer error.
- fixermark 12y ago
  I'm not sure if you're being sarcastic. On the chance that you're not, you may very well be working in a space where you haven't had to either port your OpenGL-utilizing app to another hardware platform with an OpenGL API, or you haven't needed the "deeper magic" parts of OpenGL that become necessary when you get close to the limits of hardware capabilities. Which means I envy you, in short. ;)
  - Cocodyne1 12y ago
    Is that why I was downvoted? Seems petty.
npsimons 12y ago
OpenGL might be broken, but Direct3D and DirectX are not the solution. Otherwise, you might as well just correct yourself and say "Windows gaming" not "PC gaming". And clinging to a different single vendor's proprietary standard doesn't seem like a good idea either.
- Tuna-Fish 12y ago
  Maybe that's why his blog post was full of links to Mantle.
zurn 12y ago
> The GL model, placing the compiler in the driver, is WRONG How does he figure OpenGL mandates this? OpenGL allows a (caching) GLSL compiler to be part of the OS OpenGL support, leaving drivers to consume bytecode or some other kind of IR.
VikingCoder 12y ago
Reason #2 is chicken and egg. I'm not excusing OpenGL for this fact, I'm just stating that if people cared about the quality of OpenGL drivers and made purchasing decisions based on that, then you bet your ass the manufacturers would make the OpenGL drivers better.
icambron 12y ago
I don't know anything about graphics programming, but I couldn't make any sense of this: > While the current GL spec is at feature parity with DX11 (even slightly ahead), the lowest common denominator implementation is not, and this is the thing that I as a developer care about. Isn't DX restricted to Windows, meaning its lowest common denominator implementation is nothing at all?
- tormeh 12y ago
  The driver vendors (AMD, Intel, Nvidia) are the implementers of the standards. That's basically the only thing I know about this that you don't, I think.
- DSMan195276 12y ago
  That's exactly what I was thinking. In fact, IIRC the only other DX implementation you might consider is the DX version that comes with wine, which I think currently supports DX 9 (Depending on your definition of support). The irony is of course that the wine version is written in OpenGL.
- MBCook 12y ago
  What I believe he means is that if you have an OpenGL driver that implements the ENTIRE specification (correctly and in a performant manor) then you have basically all the features of a modern DirectX 11 card available. The problem is that many OpenGL drivers implement the base OpenGL specs and then a couple of extensions here and there. Because of this you can't rely on what's available and you end up with something that's more akin to a mix of many previous versions of DirectX: some advanced capabilities but many basic ones missing.
- alkonaut 12y ago
  You pick one API per platform. With DX you get All PC:s that run windows (I.e almost all gaming PC:s), as well as Xbox. If your game targets another platform such as PlayStation you pick LibGCM or similar. GL can be used as a back end for some/all platforms but you can't use a single GL backend for all platforms because of the differences. The fact that DX is hugely popular as a backend for Win/Xbox even for games/engines that also target non-DX platforms is pretty compelling evidence of its popularity among developers.
jmpeax 12y ago
I've written an in-house visualization program in OpenGL that runs on Mac and Windows. These articles just make me laugh, especially the bit where they talk about cross platform being a myth, then follow on with the virtues of DirectX.
- lilsunnybee 12y ago
  The article specifies OpenGL being deficient for high-performance gaming, not so much for other graphics computing tasks.
SteveDeFacto 12y ago
I can't agree 100% with everything in the article but the part about GLSL is spot on.
ksec 12y ago
With the traction of iOS Ecosystem. I think Apple could have created its own API, or even just reuse Mantle or use it as a base for a new API. This certainly wasn't possible when Mac was the minority. But now even if Apple gets only 10% of the Phone market there is still a huge userbase. No longer bounded by OpenGL.

OpenGL Is Broken

156 points by watermel0n 12y ago

feistyio 12y ago

As is your server.

maaku 12y ago

You're webserver is broken. Anyone have a cached link?

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
wlesieutre 12y ago
http://webcache.googleusercontent.com/search?q=cache:oKkIlJG5tAoJ:www.joshbarczak.com/blog/%3Fp%3D154+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:oKkIlJG...
robin_reala 12y ago
https://webcache.googleusercontent.com/search?q=cache:http%3A%2F%2Fwww.joshbarczak.com%2Fblog%2F%3Fp%3D154 https://webcache.googleusercontent.com/search?q=cache:http%3... !cache in DDG will get that for you in future.

pyalot2 12y ago

This post is factually wrong, and misguided. Here's why: #Preamble: Except on Windows you cannot run Direct3D anywhere else. Unless you plan not to publish on Android, iOS, OSX, Linux, Steambox, PS4 etc. you will have to target OpenGL, no matter how much you dislike it. #1: Yes the lowest common denominator issue is annoying. However, in some cases you can make use of varying features by implementing different renderpaths, and in other cases it doesn't matter much. But factually wrong is that there would be something like a "restricted subset of GL4". Such a thing does not exist. You either have GL4 core with all its features, or you don't. Perhaps author means that GL4 isn't available everywhere, and they have to fall back to GL3? #2: Yes driver quality for OpenGL is bad. It is getting better though, and I'd suggest rather than complaining about OpenGL, how about you complain about Microsoft, Dell, HP, Nvidia, AMD etc.? #compiler in the driver: Factually this conclusion is completely backwards. First of all the syntactic compile overhead isn't what makes compilation slow necessairly. GCC can compile dozens of megabytes of C source code in a very short time (<10ms). Drivers may not implement their lexers etc. quite well, but that's not the failing of the specification. Secondly, Direct3D is also moving away from its intermediary bytecode compile target, and is favoring delivery of HLSL source code more. #Threading: As author mentions himself, DX11 didn't manage to solve this issue. In fact, the issue isn't with OpenGL at all. It's in the nature of GPUs and how drivers talk to them. Again author seems to be railing against the wrong machine. #Sampler state: Again factually wrong information. This extension http://www.opengl.org/registry/specs/ARB/sampler_objects.txt http://www.opengl.org/registry/specs/ARB/sampler_objects.txt allows to decouple texture state from sampler state. This has been elevated to core functionality in GL4. 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. 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. #Many ways to do the same thing: Again many factual errors. Most of the "many ways" that author is railing against are legacy functions, that are not available in core profile. It's considered extremely bad taste to run a compatibility (to earlier versions) profile and mix&mash various strata of APIs together. That'd be a bit like using Direct3D 8 and 11 functionality in the same program. Author seems to basically fail in setting up his GL context cleanly, or doesn't even know what "core profile" means. #Remainder: Lots of handwaving about various vaguely defined things and objecting to condjmp in the driver, again, author seems to be railing against the wrong machine. Conclusion: Around 90% of the article is garbage. But sure, OpenGL isn't perfect, and it's got its warts, like everything, and it should be improved. But how about you get the facts right next time?

leorocky 12y ago
> how about you complain about Microsoft, Dell, HP, Nvidia, AMD etc.? These companies are businesses that need a business reason to support your platform. Until more people are playing triple A games on platforms that use OpenGL you can't really fault them for spending money when it doesn't make sense. Apple designs its own chips for its mobile device so I'd think the OpenGL on iOS would have better driver support.
- pyalot2 12y ago
  OpenGL is the only thing you get on iOS. There is no Direct3D on iOS. Likewise, it's the only thing you get on PS4, Steambox, OSX etc. But that's not my issue, I acknowledge freely that OpenGL drivers are bad. I just don't quite see how that's a failing of OpenGL, rather than the vendors who actually implement the drivers.
  - cwyers 12y ago
    Well, no, Sony has its own low-level API that you can use on the PS4[0], and because all PS4s use the same GPU you don't have to worry about a lot of what OpenGL has to offer you in terms of abstracting away the underlying hardware, if all you care about is the PS4. http://arstechnica.com/gaming/2013/03/sony-dives-deep-into-the-ps4s-hardware-power-controller-features-at-gdc/ http://arstechnica.com/gaming/2013/03/sony-dives-deep-into-t...
  - fixermark 12y ago
    The bigger problem is a failing of the ecosystem at large; there's an insufficiently toothful agency policing the vendors and a lack of gold-seal certification that matters, leaving space for vendors to do whatever gets the card out the door before the competition. OpenGL's breadth as an API definitely doesn't help ("now that you've implemented direct-buffer rendering, let's go implement all that glVertex crap that lets you do the exact same thing, only slower! Your library coders have infinite time, right?"). But I doubt it's the root cause of the frustration; the "hit the benchmarks and beat ATI out the door this Christmas" ecosystem is my biggest gripe. I've had to deal with cards that explicitly lie to the software about the capabilities by specifying they support a shader feature that's implemented in software without acceleration (!!!). There's no way to tell via the software that the driver is emulating the feature besides enabling it and noticing your engine now performs in the seconds-per-frame range. So we blacklist the card from that feature set and move on, because that's what you do when you're a game engine developer.

fixermark 12y ago

Quite a few of these issues (especially in the "Too many ways to do the same thing" category) relate to OpenGL's age as an API, which is something Direct3D's design was able to learn from and improve upon. OpenGL's origin was as a vector-based drawing tool for CAD applications which was repurposed to games; D3D was targeted for performant rendering with games as a specific target. This is demonstrated by some key features necessary for performant games (clock synchronization to avoid 'tearing' comes immediately to mind) that are core to the D3D spec and extensions to the OpenGL spec. There's also a bit of a cultural issue; if you learn OpenGL from the 'red book,' you'll learn the function-per-primitive API first, which is precisely the wrong tool for the job in making a performant game. Really, the OpenGL API is almost multiple APIs these days; if you're using one flow of how to render your primitives, the other flow is downright toxic to your rendering engine (in that it's going to muck about with your GL state in ways that you shouldn't burn mental energy predicting). Some of this is ameliorated by the OpenGL ES standard, which throws away a big chunk of the redundancy. But I'm not yet convinced that OpenGL has gotten away from its philosophical roots as a performance-secondary CAD API, which continues to dog its efforts to grow to serve game development needs. The fact that it's functionally the only choice for 3D rendering on non-Windows platforms is more testament to the nature of the hardware-software ecosystem of graphics accelerators (and the creative doggedness of game developers) than the merits of the language.

Aardwolf 12y ago
It would be interesting if they made a high-performance variant of the red book using the latest standard, e.g. the "bright red" book or "crimson book" or so :)
- fdr_cs 12y ago
  Both 5th and 6th editions of OpenGL Superbible use only Core Profile functionality. It's the best way to start OpenGL nowadays
- TuringTest 12y ago
  Something like this? http://www.arcsynthesis.org/gltut/ http://www.arcsynthesis.org/gltut/

foxhill 12y ago

theory: articles of the form: "X is broken", "X is wrong", or some other equally dramatic statement, say almost exactly the same thing; nothing.

sdfjkl 12y ago
While I hate link baiting as much as the next guy, I find myself agreeing with most of the things he says about OpenGL.
- foxhill 12y ago
  if perhaps he suggested how one might change things to make it better, then maybe his arguments would have merit. right now, all this is, is a list of his personal complaints of the API. and hence, it's aimed at the users of OpenGL. i.e, we're already aware of the crap that's in the standard. this is not news to us. upvoting and supporting this sort of article is a bee's dick away from a programmers circle-jerk. > there are languages that people hate, then there are languages that do not get used. replace language with API.
- cheery 12y ago
  Too bad there's no alternatives.
deluvas 12y ago
Too bad you're getting downvoted, because it's true.

foxhill 12y ago

if perhaps he suggested how one might change things to make it better, then maybe his arguments would have merit. right now, all this is, is a list of his personal complaints of the API. and hence, it's aimed at the users of OpenGL. i.e, we're already aware of the crap that's in the standard. this is not news to us. upvoting and supporting this sort of article is a hairs width away from a programmers circle-jerk. > there are languages that people hate, then there are languages that do not get used. replace language with API. edit: so, my comments are dead. i wasn't aware dissent was so strongly discouraged.

anotherfadjs 12y ago

You can use pre-compiled binary GLSL objects during development with ARB_get_program_binary. And yes OpenGL is broken and painful, live with it.

CmonDev 12y ago

And it will never be properly fixed due to backwards-compatibility requirements - just hack-patched. Just like web (HTML/CSS/JS).

druidsbane 12y ago

Well-reasoned response: http://timothylottes.blogspot.com/2014/05/re-joshua-barczaks-opengl-is-broken.html http://timothylottes.blogspot.com/2014/05/re-joshua-barczaks...

mmarks 12y ago
I nod my head in agreement with most of these OpenGL are broken articles. I've work on the OpenGL version of Call of Duty, Civilization, and more for the Mac. I think Timothy misses the real point on driver quality. https://medium.com/@michael_marks/opengl-for-real-world-games-7d0f4d35891c https://medium.com/@michael_marks/opengl-for-real-world-game...

Mikeb85 12y ago

So the solution he proposes at the end is to use Mantle? AMD has already proven themselves incompetent (or are they only unwilling?) at implementing OpenGL, unable to compete with either Intel or Nvidia, and now they want to fragment graphics APIs? And this is the 'solution'? As for OpenGL's issues - that's what happens when a spec gets old enough. But the fact remains, it's the only graphics API that could be called 'universal', they have modernized the spec, and despite all its failings, somehow it still delivers better performance than DirectX...

alariccole 12y ago

Your site is broken. http://webcache.googleusercontent.com/search?q=cache:http://www.joshbarczak.com/blog/?p=154 http://webcache.googleusercontent.com/search?q=cache:http://...

shmerl 12y ago

What is the current stance of Nvidia and Intel on implementing Mantle support? And what are the chances of mobile GPU makers doing the same? Is it easier to make a better OpenGL 5, or to adopt Mantle across all GPU manufacturers?

corysama 12y ago
Even if it is technically quite feasible, I would be seriously surprised if Nvidia and Intel implement Mantle if only for political reasons. However, they definitely will implement DX12 --which as far as I can tell is pretty much the same thing as Mantle except explicitly multi-vendor. If Mantle was a tap on OGL's door, DX12 is a full-on wake-up call. Back when I worked in Windows/console games, my market demanded D3D (+ sony/nintendo's wacky custom APIs). Now I work in mobile and my customers demand GLES. GL advocates used to cry "GL has the better tech! D3D only wins because of politics! Boo!" It will be quite a turn if they switch tunes to "D3D has better tech, but GL still wins because of politics! Yay!" DX12 API Preview vid http://channel9.msdn.com/Events/Build/2014/3-564 http://channel9.msdn.com/Events/Build/2014/3-564 DX12 API Preview slides http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fvideo.ch9.ms%2fsessions%2fbuild%2f2014%2f3-564.pptx http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%...
- shmerl 12y ago
  DX12 is not the way forward because it remeains MS only and there is no indication that MS is interested in opening it up. The way forward is either creating a new open API which all manufacturers would support (Mantle, or whatever), or seriously improving OpenGL if it's possible.
- Tmmrn 12y ago
  > It will be quite a turn if they switch tunes to "D3D has better tech, but GL still wins because of politics! Yay!" What are you actually comparing? Yet to be released DirectX12 v.s. OpenGL 4.4? Or v.s. what will actually "compete" against it, once it is actually released and used, OpenGL 4.5 or 5.0? Are you just assuming future versions will be worse than Direct3D? "used to cry"? That sounds all very fair and objective.

raverbashing 12y ago

I think what's broken is not OpenGL, D3D, etc What's broken is that the abstraction between graphics card and data (on the screen) is too big We don't have troublesome/fat drivers as these since the "Softmodem" days and even then (Wifi is also complicated) It's too big of a gap. In 2D graphics, you send graphical data and it is displayed. You may even write it directly to memory after some setup. Audio, same thing. Network, it's bytes to the wire. Disk drive, "write these bytes to sector X" (yes, it's more complicated then that, still) With 3D, we have two APIs that have an awful amount of work to do between the getting the data and displaying it. I'll profess my ignorance in the low-level aspects, I only know "GlTriangle" , OpenGL 101 kind of stuff, and I have no idea how: 1 - this is sent to the videocard, 2 - how does it decide to turn that into what we see on the screen. Compared to the other drivers this is a lot of work and a lot of possibilities of getting this wrong. Adding GPGPU stuff makes it easier in one aspect and more complicated in other aspects. We don't have a generic way of producing equal results from equal inputs (not even the same programming environment is available) We don't have OpenGL, we have "this OpenGL works on nVidia, this other one works on ATI, this one works on iOS, or sometimes it doesn't work anywhere even though it might be officially allowed"

zanny 12y ago
> We don't have OpenGL, we have "this OpenGL works on nVidia, this other one works on ATI, this one works on iOS, or sometimes it doesn't work anywhere even though it might be officially allowed" But this is just the shortfall failure to be standards compliant. We have multiple ARM implementations in CPU space, we have two vendors x86 CPUs, we have all kinds of wireless cards, but assembly on one ARM core better run on another, your x86 binary better run on ARM or Intel chips unless you use vendor specific extensions, and your wireless radio better process inbound data properly regardless of the sender. I think the real problem is that in the massively parallel pipeline architecture space (aka, gpus, but they are more than just graphics processors anymore) is that they aren't treated like proper programmable computers. What we should have are compilers to build ASM binaries for each architecture, and sane ISAs. That would mean in the present tense you would need Intel: preSB, SB, IVB, Haswell, Broadwell, Skylake, etc compilers. I've never read their ISA documentation, so I don't know which of these have common core so that you could treat it like a CPU - ie, base instruction set with extensions like SSE or NEON. I do imagine though if we weren't working at such an absurdly high level, we would see graphics hardware conform to the same model as CPUs - common ISA, with multiple implementations. I guess the problem there is that the way all modern ISAs are handled is ridiculous and stupid. Intel "owns" x86, ARM "owns" itself, etc. The reason we don't have reasonable CPU competition is that you don't just compete in hardware implementation, you either need to pay extortion to use what is effectively the same API - the same ISA - and that is one of the strengths of the graphics industry. The effective ISA that software is built against is predominantly open (most GPU code is openGL, despite how many directX games there are). We can see the difference - very little hardware runs DirectX because they have to pay MS the privilege to support it, and then it isn't even a standard at all so you can't use it on anything but Windows. It is congruent with proprietary ISAs for cpus. An example of a non-proprietary ISA is SPARC. I've never really looked into how good an ISA it actually is, but it is royalty free unless you want to use the branding - you can implement your own SPARC cpus without paying jack, the way it should be. So like I said, what we really need is a common open ISA for hardware graphics accelerators to implement, and then independently develop extensions for that can be proposed and adopted into the mainstream standard. And if that standard ever becomes overly bloated, any vendor can develop their own newer base to handle newer paradigms or fix bloat, the same way we see programming languages go. If I didn't have to figure out how to eat or didn't have another dozen things I'd want to do, I'd definitely want to see what I could manage writing a binary compiler for the SI ISA from AMD and seeing how performant you could make some other high level graphics language with compiled binaries. That is kind of what they did with Mantle, but their continued showing of not making any effort to open that language up to standardization or even just publishing it at all shows that it certainly won't be the answer.

espadrine 12y ago

The "compiler in the driver" part of this post sounds awfully like the "asm.js vs. NaCl" debate. Sure, building an IR from scratch is fun. But making it truly cross-platform and ready for many usages is really hard. Also, the GLSL source is an IR between the programmer's intent and the driver's behaviour. Code is just another type of binary. It is just slightly harder to parse, but not by much; without performance comparisons, a complaint about how hard it is to parse code is invalid. Feeding the driver GLSL can also yield much clearer error messages for programmers. I can only imagine what kinds of error messages the IR compiler would produce. Sure, hopefully, our cross-platform IR would be accepted by all GPUs without pain, but that's improbable. Regardless, starting from a clean slate is much harder than working our way from the current state to an improved OpenGL. Just like few browsers are on board with NaCl, few GPU makers would be on board with a brand new design.

fzltrp 12y ago
> Sure, building an IR from scratch is fun. But making it truly cross-platform and ready for many usages is really hard. It's not that hard, as long it remains as close as possible to the source language (ie. GLSL). Iow, as the OP is advocating for, an AST of the shaders. This removes the cost of parsing the source code (but requires on the other hand to validate the AST, so this isn't exactly a complete gain, but definitely an progress compilation wise). However, I suppose that what motivated the choice of using GLSL source directly is the simplicity of the approach: no need to build the GLSL scripts separately. When working with interactive tools, it's a non negligible comfort, imho. Another interesting aspect is the ability to build the scripts dynamically, like people do with SQL. I wonder if this approach is used by professional game studios.

AshleysBrain 12y ago

I think the difficult thing about OpenGL is it is hard to learn. The core profile of the latest version might be nice, but in practice there are still a wide range of OpenGL versions in use, so you have to learn the various ways of doing things through the OpenGL versions, or code against a crufty old version which is the lowest common denominator. Then there are various driver issues, platform-specifics around context creation, and so on. Overall it's a pretty tough chestnut if you're not going to use it directly instead of relying on an engine/framework that has figured out lots of that already. Mobile on the other hand seems decent - OpenGL ES 2+ seems to be a well-designed clean and relatively minimal API with widespread support.

Cocodyne1 12y ago

OpenGL works fine for me, so it must be user/programmer error.

fixermark 12y ago
I'm not sure if you're being sarcastic. On the chance that you're not, you may very well be working in a space where you haven't had to either port your OpenGL-utilizing app to another hardware platform with an OpenGL API, or you haven't needed the "deeper magic" parts of OpenGL that become necessary when you get close to the limits of hardware capabilities. Which means I envy you, in short. ;)
- Cocodyne1 12y ago
  Is that why I was downvoted? Seems petty.

npsimons 12y ago

OpenGL might be broken, but Direct3D and DirectX are not the solution. Otherwise, you might as well just correct yourself and say "Windows gaming" not "PC gaming". And clinging to a different single vendor's proprietary standard doesn't seem like a good idea either.

Tuna-Fish 12y ago
Maybe that's why his blog post was full of links to Mantle.

zurn 12y ago

> The GL model, placing the compiler in the driver, is WRONG How does he figure OpenGL mandates this? OpenGL allows a (caching) GLSL compiler to be part of the OS OpenGL support, leaving drivers to consume bytecode or some other kind of IR.

VikingCoder 12y ago

Reason #2 is chicken and egg. I'm not excusing OpenGL for this fact, I'm just stating that if people cared about the quality of OpenGL drivers and made purchasing decisions based on that, then you bet your ass the manufacturers would make the OpenGL drivers better.

icambron 12y ago

I don't know anything about graphics programming, but I couldn't make any sense of this: > While the current GL spec is at feature parity with DX11 (even slightly ahead), the lowest common denominator implementation is not, and this is the thing that I as a developer care about. Isn't DX restricted to Windows, meaning its lowest common denominator implementation is nothing at all?

tormeh 12y ago
The driver vendors (AMD, Intel, Nvidia) are the implementers of the standards. That's basically the only thing I know about this that you don't, I think.
DSMan195276 12y ago
That's exactly what I was thinking. In fact, IIRC the only other DX implementation you might consider is the DX version that comes with wine, which I think currently supports DX 9 (Depending on your definition of support). The irony is of course that the wine version is written in OpenGL.
MBCook 12y ago
What I believe he means is that if you have an OpenGL driver that implements the ENTIRE specification (correctly and in a performant manor) then you have basically all the features of a modern DirectX 11 card available. The problem is that many OpenGL drivers implement the base OpenGL specs and then a couple of extensions here and there. Because of this you can't rely on what's available and you end up with something that's more akin to a mix of many previous versions of DirectX: some advanced capabilities but many basic ones missing.
alkonaut 12y ago
You pick one API per platform. With DX you get All PC:s that run windows (I.e almost all gaming PC:s), as well as Xbox. If your game targets another platform such as PlayStation you pick LibGCM or similar. GL can be used as a back end for some/all platforms but you can't use a single GL backend for all platforms because of the differences. The fact that DX is hugely popular as a backend for Win/Xbox even for games/engines that also target non-DX platforms is pretty compelling evidence of its popularity among developers.

jmpeax 12y ago

I've written an in-house visualization program in OpenGL that runs on Mac and Windows. These articles just make me laugh, especially the bit where they talk about cross platform being a myth, then follow on with the virtues of DirectX.

lilsunnybee 12y ago
The article specifies OpenGL being deficient for high-performance gaming, not so much for other graphics computing tasks.

SteveDeFacto 12y ago

I can't agree 100% with everything in the article but the part about GLSL is spot on.

ksec 12y ago

With the traction of iOS Ecosystem. I think Apple could have created its own API, or even just reuse Mantle or use it as a base for a new API. This certainly wasn't possible when Mac was the minority. But now even if Apple gets only 10% of the Phone market there is still a huge userbase. No longer bounded by OpenGL.