OpenGL – OS X Mountain Lion vs. Mavericks
rk.md
rk.md
For a very long time, for example, OGL 2.1 was the only thing supported by Apple, despite numerous extensions to bring it up to feature-parity with modern OGL. Vendor extensions made programming code a mess, and many of the core concepts as embodied in the API are minefields for developers.
Don't hate on DX just because it's from Microsoft--an open re-implementation would actually help everyone.
There was a post here a few weeks ago (some dude dug up some old content of a 3D mesh of a cow in a Java viewer). And the old OpenGL and Java code "just worked".
"... and in their death throes, they gave onto us, technologies to last more than 2 years at a time. Sights and wonders never before seen only told, far outreaching the merciless grasp of the Holder of Shares."
RIP - SGI Vpro.
CAD vendors were what fucked over OpenGL for a long time, and it was only the fourth-quarter ill-fated kick by 3dlabs that gave it a programmable shader pipeline, and in turn set back the API development by another half-decade at least.
Look, "open" is not some magical fucking pixie dust you sprinkle over an abortion of an API to make it breathe life and grow up and change the world. If it was, audio in Linux wouldn't be such a shitshow, and neither would X, and neither would any number of other open APIs that everyone hates.
I do agree with you, though: rest in peace, Silicon Graphics.
EDIT: Derp on 3dfx vs 3dlabs.
I am hoping that if OpenGL becomes the most sensible choice, something else will grow out of it. Or if the reigns were handed over to FSF.
I don't think it's a very good comparision, but javascript is doing great out there in the wild. As is Linux, even with so many chefs.
It's not my area of expertise but it does ring true to me - whenever I see people complain about OpenGL they always seem to be confusing API surface with implementation details. I.e. the "legacy" parts can be shimmed to the "modern" parts without harming anyone very much.
The GL 3.3 samplers, e.g., are great. It does not require you to bind a sampler object in order to change the properties of it. However, the rest of the GL objects follow bind-change-unbind and a lot of implicit state which makes writing OpenGL libraries that can be reused highly weird because you never know what state some moron left the GL machine in.
Now GL 3.3+ is in an interesting position. They've got old functions that operate in a specific bind-change-unbind and new function that operate directly. So not only has the API not yet been fully "modernized", it's in the halfway state and it looks like it won't be pushed in one direction or the other -- just stuck in limbo for something like 3-4 revisions.
So I guess what I'm saying is, until the inconsistencies are ironed out, OpenGL still has some cruft that directly affects even the most modern GL 4.x programs.
Please read this again:
> they always seem to be confusing API surface with implementation details.
It does not have to work like a modern GPU. An API is an abstraction.
If you want to introduce a new API that is a better abstraction for current hardware that's fine, but that's not an argument to remove the earlier abstraction which is working fine for other users.
EDIT: I would also like to add that only in the strictest and most painful sense was the legacy OpenGL "just an abstraction". Before, it was a simplistic cross-platform layer over actual hardware and while abstract to a degree, hardly attempted to shield the programmer from hardware details. It's notable that the features that OpenGL "happened" to include as the "core abstract GL state machine" mapped pretty much 1-to-1 onto SGI's tiered hardware offerings at the time. In other words, what made the cut was very much based on real hardware, hence, the evolution of the API was not based on random abstractions that seemed like a good design [cough]. The legacy-GL-on-modern-hardware -- we refer to it as "fixed function emulation", since the abstraction is so far removed from actual hardware nowadays. Perhaps this isn't a "good reason" to change the abstraction, but it is notable that if the entire legacy API can be emulated using the newer API, then the legacy API may not deserve to be part of the driver (which takes a lot of time and effort to develop) so much as another library. That is to say, if one were to change it into terms of "computability", there are some things that cannot be computed using the FF, but the reverse is not true, i.e. FF can compute a proper subset of the programmable pipeline. In fact, this is pretty much the exact idea that Gallium takes in Mesa -- and why you can implement D3D / GL ES / core GL / legacy GL on top of it.
Now, on to the real issue that I raised, which is a purely API design choice. Direct state access vs bind-modify-unbind. The consequences of bind-modify-unbind have been lamented by developers for _ages_. As a response, the newer GL sampler objects do not use that. However, the old style API (you know, the thing we've been lamenting over for ages) does not have a modern equivalent. Please tell me how this has ANYTHING to do with GPUs? It's pure and simple API cruft. The API is _not_ consistent with itself.
It's slow and ugly, and very nearly cannot peacefully coexist in the API. And maintaining it requires developer resources that don't easily exist for these companies.
Look, if you want to run off and create libAncientGL and do all of the book-keeping yourself and call to the most recent GL API, go nuts, and godspeed. That doesn't mean that we should hold companies to that requirement.
There are plenty of reasons developers go to DirectX, support and tooling being two of them.
On the game consoles, outside Microsoft, regardless what is spread around, game consoles don't support OpenGL, just variations thereof or similar APIs.
For example the PS3 has OpenGL ES 1.0 combined with Cg, not GLSL. In the end most developers use Libcgm anyway.
As for the other consoles they are also other type of APIs.
In the end, the best approach is to have an API agnostic middlelayer and be independent of the underlying API.
Later on, it was asked at one GDC event if developers cared about GLSL, but since almost everyone that cares about performance on the PS3 uses Libgcm anyway, the update never happened.
Let's see if there is any noticeable improvement on lesser or older GPUs.
1. Only in developer preview and subject to change (for better and for worse).
2. Under NDA.
This does not show that Apple as a company does not really care if you are publishing a very short comparison of one tiny tiny aspect of something that is still under NDA but I doubt they do.
NDAs are overrated in general.
(In fact, I read a theory somewhere that the NDA is really just about corporate competitive advantage for some legal reason. I forget what it was; it might have been something with the date a technology becomes public re: patent law.)
That said, more than almost anything else, I'd be wary about posting benchmarks. Performance is subject to change wildly between the developer betas and the final product. It could get better with optimizations and taking out debug code; it could get worse if some optimizations are found to be unstable.
If it was just, "Hey, this is awesome! They've implemented through OpenGL 4.1 and their implemenation is significantly faster across all OGL versions!" I'd be less worried. I can imagine a graphics programmer getting twitchy about early numbers.
(Just saying this to support what you said)
I’m not sure whether that would actually hold up legally – but that’s the theory.
(Also, Apple doesn’t seem to be very interested in actually stopping sites like Macrumors – which are filled to the brim with every tiny detail about the iOS and OS X DP – from actually publishing that. So I guess they are even less interested in going after people who do not even show videos or screenshots.)
That’s correct. When you buy a Mac, you don’t need to download extra drivers. Only if you buy a Mac Pro and later install a different (or additional) PCI graphics card, you may need to download drivers.
The only PCIe expansion capability available on any mac (including the new mac pro) is thunderbolt. The new mac pro does not have any internal expansion.
You can however, use something like [this](http://www.sonnettech.com/product/echoexpresschassis.html), as long as you realize that you only have access to PCIe x4 bandwidth.
I've also not seen any posts of anyone actually doing this yet.
Nominally these are to support higher end cards for things like CUDA and OpenCL. Interestingly, though, the official drivers contained in updates from Apple have evolved support for pretty much every nVidia card since 2010, and recently starting gaining support for the AMD 7xxx series. For example I run a hackintosh with a fully enabled GTX 470. In Snow Leopard days I had use the nVidia supplied drivers for their workstation cards, these days it Just Works.
Yes, I'm sticking to Mac OS X
For example, OSX has really bad (read: no) support for hardware slightly deviating outside of its niche. It also uses an arguably-broken UI metaphor, and has no truly good package management story.
While it is well known that Linux supports the most hardware devices out there (in absolute terms) and Windows is most likely to support currently common hardware, neither allows one to rely on a recent version of OpenGL being available.
On Windows one must install drivers to get OpenGL support because GPU manufacturers focus on the very platform-specific Direct3D at the expense of everything else, on Linux support is spotty and only through binary blobs because the same GPU manufacturers don't provide full open source drivers for the hardware their customers paid for.
I was lamenting the state of standards compliance in general and OpenGL in particular; in this particular case OS X does pretty well.
Suppose I had GL 4.3 capable hardware.
Closed Source Drivers on Windows = OpenGL 4.3
Closed Source Drivers on Linux = OpenGL 4.3
Open Source Drivers on Linux = OpenGL 3.1 [best case]
Closed Source Drivers on MacOS = OpenGL 3.2
My Game Engine Requires = OpenGL 3.3
---
As you can imagine, that means:
If you're running Linux on open source -> no
If you're running Mac at all -> no
In fact, what is ironic is the ONLY systems in the ENTIRE PLANET that can run this game are ones using proprietary drivers, specifically Windows and *NIX (but not MacOS)
Windows also generally will try and install driver updates as soon as they become available--this hardly makes OGL some magical burden to keep up-to-date.
If anything, OSX has been lagging behind hard until recently.
The intent of the Mac Pro, when you look at it, is to be a small, lightweight, ridiculously powerful OpenCL workstation. It has a single Xeon to handle systems tasks, two FirePros (one of which does graphics and computation, the other does only computation), and PCIe SSDs to keep the OpenCL cores fed and store their data.
It seems OpenGL, didn't move or improve much at all in recent years and OpenCL has had much news.
The more people that request it the more resources they throw at things. So if they keep this yearly update schedule maybe mountain mavericks or whatever the hell they name the next release might have it.
I submitted a bug report to help things along. I don't find posting non useful replies on Hacker News to be very productive at getting change to occur. Apple is far from perfect, but they do pay attention to how many people complain about the same thing in their bug tracker.
Would it be ideal if Apple did everything HN commentators wanted? Well no, most of the requests here can be a bit ludicrous. But if you're a developer on Apple and you do not file a bug report specifying the need for up to date OpenGL, complaining here isn't productive. I will leave the hyperbole about "far from perfect" aside as all human endeavors are far from perfect and hate the platform wars that proliferate here.
Maybe OpenGL is better with apple, but C++ is not. Shoving Nextstep under programmer's throats is really a weird strategy.
No, it is like any vendor that makes developers stick with their own technology. This has been happening in commercial software since the dawn of computing.
And honestly, right clicking with mac, what a nightmare, always bringing the throbber. When I think about it, apple delivers the software that works with the hardware, but the soft is just cool, it's not really nice to work with. Most features comes from unix anyway. While microsoft was hardware agnostic and allowed the computer industry to grow, Apple just comes in with apparatus and just want people to forget the pain of what allowed the computer industry to grow by delivering both soft and hardware.
You can't make programmers learn a language which works in so many different ways, and expect to create a monopoly on such apps. Or maybe it will take time for crowds to forgets C++ and use cocoa.
Besides, the fact windows has non portable code, doesn't mean OSX should too. Especially if it uses unix as a base.
Did you ever wrote portable GUI applications across UNIX systems using only UNIX standards?
> XWindows and OpenGL are not part of POSIX.
I don't really care about POSIX, I care about being able to recompile apps for a new OS, without having to rewrite core parts or change the design. I guess people would start to make new apps for the sake of apple.
And by the way, what's the point of Cocoa compared to other existing things ? Is GUI programming that much important, now that everybody is using html and js ? Is it worth changing the wheels for the sake of a language paradigm ? At the kernel level, I don't see why there's a need for cocoa.
C++ is great at a lot of things, but interface glue is not one of them.
All C++ compilers have vendor extensions.
congressmen ! Seriously ?
> [your preferred development stack] sucks
I don't prefer anything, but making things work between systems is a pain, and I thought portable languages were the thing that allowed those systems to run the same programs.
I just think that trashing portions of technologies that worked on other systems, is debatable.
> Clearly, [vendor of your preferred development stack] should go spend many years rewriting everything so that my mind can continue living comfortably in the box it's in, safe from the pain of having to learn something different.
Yeah, maybe. At the time I adopted Ogre3D, I thought its code would run on any OS. I would really like to know the good reasons that push companies to break backward compatibility. Carbon comes to mind. Most other OSes think backward compatibility is important. But now, we move faster than light, screw the weak ones who won't learn all the new stuff !