Hacker News Reader

> OpenGL is an outdated design for modern GPUs.

The thing is, in its entire lifetime OpenGL was never meant to be a GPU abstraction layer - that only happened during GeForce2's time (and only for Nvidia). Even SGI's implementation was doing a lot of stuff on the CPU (and SGI even had a pure CPU implementation). OpenGL was always meant to be a high lever immediate graphics API (immediate here meaning as opposed to retained/scene graph APIs like OpenInventor).

> By the way, OpenGL still works on macOS 10.15. Deprecated does not mean it's not working.

Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to keeping things working.

It seems to me then that OpenGL should have been a library instead of a driver all along. Its original intent unfortunately has no bearing on what it has become in the meantime.

> Yeah but as it can clearly be seen, you cannot rely on Apple when it comes to keeping things working.

Well yeah that's what deprecated means. At the moment, developers have a bit longer to get on with the times though, so that's nice I guess.

> should have been a library instead of a driver all along

This would have required there to be a lower-level interface that different vendors could all implement, which was not the case for early graphics hardware. In the decades since graphics hardware has all evolved to look more or less the same to SW (so vulkan became a nice fit), but that wasn't always the case.

FWIW, OpenGL is quite broken. It works but it periodically glitches or does something weird in even minor point releases.

What you're describing has nothing to do with the OpenGL standard but of graphics drivers (OpenGL implementations).

Yes, I’m talking about Apple’s implementation of OpenGL.

And I think it was a big failure not to adopt Iris Inventor as well.

Every OpenGL newbie has to go through the rite of passage of assembling their own SDK for dealing with fonts, textures, materials, math, meshes,...

Whereas all competing APIs provide such features out of the box on their SDKs, including the console ones.

Plus there is this myth about portability, when any relatively big OpenGL application is full of extensions and multiple code paths to deal with OEM specific features, driver bugs or hardware glitches.

Then there is the little issue that OpenGL, OpenGL ES and WebGL are only superficially alike.

This is blatantly false.

You may be thinking about OpenGL 1.x and the fixed pipeline. Modern OpenGL is perfectly capable of running virtually every game and professional app out there.

OpenGL does NOT work on macOS and hasn’t worked for a very long time. Apple only allows to use an ancient version of OpenGL, which is not really my definition of “working”.

Nobody is going to ever remove OpenGL from Linux (or Windows) drivers. OpenGL/D3D powers everything there. Vulkan and Direct3D 12 are just the lowest level and are not a replacement for OpenGL nor Direct3D 11. Drivers may implement them on top of Vulkan/D3D12, but removing? Never.

Finally, Apple has never told anybody to use MoltenVK because they don’t want you to. And I would not be surprised if they end up banning such layers if they find they get popular.

Better start paying attention to what the Vulkan folks are doing, Khronos and friends haven been pushing for OpenGL deprecation for quite a while now.

https://xdc2019.x.org/event/5/contributions/329/attachments/..., 2nd slide

This is just one example, here is a nice gathering at latest Reboot Develop Blue 2019

https://www.youtube.com/watch?v=hcgG1RQ-BJM

As for Windows, OpenGL ICD drivers only run in legacy Win32 mode, UWP and Win32 sandbox mode doesn't allow for ICD drivers.

My application, does precisely what i want in terms of graphics, and runs at 600FPS. Explain to me why my users would benefit from me spending months switching to a different API? Life is too short for that. The loosers in all this are the Mac users. The reason to support Mac is to be nice to the users, not because it makes financial sense. If apple is going to actively make it harder why bother?

> Explain to me why my users would benefit from me spending months switching to a different API?

The idea is that leaving behind old APIs will benefit driver and system stability for the entire ecosystem, benefiting your users in other ways. You might disagree with that view, but Apple is not doing this out of spite alone.

I'm not sure that switching to use a library like MoltenGL for this stuff would take months either, but you're in a better position to judge that I guess.

Or Apple could do it! if its possible to support usigng a wrapper, Apple should make the wraper part of the API, why push the responsibility of backwards copatibility over to developers?

If you want to argue Apple is handling this poorly from a community perspective, you'll find no argument with me.

The reason Apple is doing this in this poor way is that they seem to want to push Metal as the answer. They want incentives for developers to move to Metal by making their lives more difficult on OpenGL, because even with libraries those libraries must be maintained and included. They don't want to bear responsibility for this legacy. I'm explaining, not defending.

This is the direct opposite to the Linux ecosystem, where Gallium3D not only facilitates both OpenGL and Vulkan, but has had attempted Direct3D implementations in the past. Yet another case where Linux has the "everything and the kitchen sink approach", and Apple just flat out dictates a single choice to everybody. That attitude sometimes helps Apple, but sometimes it doesn't.

Mesa Gallium 3D is not an API intended for use by applications. It is a mechanism that allows to share functionality among drivers. Yes, it is possible to create state trackers on top of it, but that will be part of Mesa. It has no public API.

Even among Mesa drivers, usage of Gallium 3D is not mandatory. If the driver team thinks it will make their job easier, they can use it. If they think it won't, they won't. Intel 965 driver (the current driver for Intel GPUs) doesn't use Gallium, for example. The new one ("Iris"), currently in the works, will. For a long time, the only driver that used Gallium 3D was only the AMD one.

You are falling into a common trap these days. There is a difference between API (remember the I stands for interface) and implementation. There is no reason a vendor can't completely change how drivers work without the application having any idea. There is nothing about the API that says it needs to push complexity onto the driver, but you are describing these implementations as inevitability.

IMO the issue is not so much that Apple is leaving stuff behind, but that it makes drastic decisions and generally does not communicate its plans.

For example in one of the email responses someone from Apple says that Carbon was a temporary solution but quite frankly that was never clear from the outside world. It seems there were even plans to make Carbon 64 bits that were scratched at the last minute.

Same with the hardware. One day out of the blue Apple announced its new laptops without USB-A ports. Even 3 years later USB-A is still one of the most used peripheral ports in the PC world (including Mac and Windows). Even Apple does not ship peripherals with USB-C cables other than adapters. AFAIK its mice and keyboards still ship with USB-A cables for charging.

These tactics are maybe ok for the consumer world but not for professionals who need reliability above all else.

Sorry, I was a teenager and fairly anti-Apple even at the time. When carbon was introduced I don't see how Carbon could have ever been seen as anything other than a temporary solution. I would have to go back and watch the original introduction, but I even seem to recall that general feeling from the event. So I guess I'm just not understanding your viewpoint here.

USB-A still works, you just need a compatibility layer (a dongle).

OpenGL has been deprecated for years. Why are people reacting like this is a new development.

>USB-A still works, you just need a compatibility layer (a dongle).

Not even that, a cable will do. I have zero dongles, and just bought a few tens of $ USB-C to X cables...

>USB-A still works, you just need a compatibility layer (a dongle).

Assuming you work at a company willing to spend the money on official Apple dongles and not cheap flakey clones.

Unfortunately few companies will do that and now all Apple I/O goes through cheap unreliable dongles.

When Mac stopped supporting NVIDIA the Mac users became losers. They missed out on all the AI and other GPGPU work.

There’s more than meets the eyes when it comes to the Nvidia/Apple situation. From what I’ve heard a big part of Apple’s problem has to do with the quality of Nvidia’s drivers — Apple is requiring that a bar be met, and Nvidia isn’t meeting it.

I can’t verify this claim, but given my personal experience it makes perfect sense. I run a 980 Ti alongside a 950 in my hackintosh tower and graphical glitches on the desktop happen pretty regularly despite both cards being perfectly healthy.

The other thing is that historically, Apple has been unwilling to differentiate the drivers between consumer and workstation cards because generally speaking that concept is kind of silly. Everybody should have workstation-class stability, not just those who shell out 3-5x more cash for a workstation card. It’s obvious why Nvidia would take issue with this,

> There’s more than meets the eyes when it comes to the Nvidia/Apple situation. From what I’ve heard a big part of Apple’s problem has to do with the quality of Nvidia’s drivers — Apple is requiring that a bet be met, and Nvidia isn’t meeting it.

Then Apple needs to dig down into their pocket, maybe they’ve got some extra money there, and solve this problem.

> I run a 980 Ti alongside a 950 in my hackintosh tower and graphical glitches on the desktop happen pretty regularly despite both cards being perfectly healthy.

The Nvidia web drivers are not great but there are so many factors that could be producing those glitches.

I've built about a dozen hackintoshes since 2010 and while I've experienced many problems I personally haver never seen graphical glitches.

I don't think it's fair to expect the same level of reliability from a frankenstein you've built yourself than a commercial product.

I would normally agree but at this point, hackintosh users are probably one of the largest groups of people making use of the Nvidia web drivers… the only others are going to be old Mac Pro holdouts and the tiny number of Mac users using Nvidia cards as eGPUs.

I think in my case specifically the graphical glitches are caused by having dual GPUs. That’s a somewhat uncommon configuration, but not so strange as to not test for.

Yes but the web drivers users are probably less than 1% of all Nvidia users.

I don't have any graphical glitches with the nVidia Web Drivers. I've used them with a GTX 970, and GTX 980 Ti, and GTX 1070, and a GTX 1080 Ti over the years. They have consistently worked fine.

Remember Bumpgate? Nvidia shipped faulty GPUs to Apple (among others including Dell and HP) which caused hardware failures in around 40% of devices, which Apple had to replace. NVidia refused to acknowledge it was their problem/fault, and even went as far as trying to sue Apple, Dell et al. As a result, no more Nvidia on Apple platforms. I can't say I blame them to be fair...

>Explain to me why my users would benefit from me spending months switching to a different API?

Because as a user I don't want apps forcing extra baggage like old APIs to be supported forever in the OS. Nor I want apps that are fossilized and don't take advantage of new platform features.

If I didn't care for apps being Mac-specific and taking advantage of what the platform has to offer and moving on with the platform, I'd just as well use Windows or Linux (and vice versa).

If such mandatory "new platform features" dont have anything to offer for a program to make it better, updating it brings in absolutely nothing for the user but the ability to continue to use the program.

I think it is pretty unreasonable to require developers to rewrite their programs periodically just because there is a some new feature in some new API.

Also, software that gets updated just for the sake of it usually ends up worse than before.

I think as a user you shouldn't need to see or know anything about APIs or OS internals. Your apps should just work.

And yet there are decades of apps not supporting new UI features, being unstable or insecure because they were slow to adopt new APIs. This is a balance: Windows font rendering, color management, and resolution scaling took ages to stabilize because things working reduces pressure on the vendors to update.

I think it would have been a lot more palatable if they hadn't gone off and made their own API (why not Vulkan?)

> OpenGL is an outdated design for modern GPUs. Its featureset and architecture is too high level, leading to more buggy drivers and complicated legacy support.

This is only a problem for game developers who live right on the GPU hardware and need to squeeze absolutely all the performance out of it. Which is probably a small number of admittedly very important developers: Game engines and AAA studios. For the rest of developers who have more modest requirements, I don't really understand what "modern" graphics APIs provide, besides tons of extra boilerplate code and headaches.

When I was a graphics programming newbie, it was great to have the whole fixed function pipeline all set up and ready for me to experiment and learn. If I had to learn from nothing on Vulkan, I'd probably have given up before the first 1000 lines. Drawing a triangle in OpenGL vs. Vulkan: http://sol.gfxile.net/temp/hellotriangle.png

It's so strange--in most of the software world, newer APIs and tools tend to be higher and higher level abstractions. "Modern" Electron apps run Javascript, HTML and CSS on an embedded browser which itself running on a high-level native toolkit which is probably written in C or C++, which compiles to assembly, etc. You can have a web server in one line of python. In contrast, the more modern graphics APIs get, the lower-level and more verbose they get.

As one of those graphics developers that doesn't need to squeeze absolutely all the performance out of a GPU, I moved into middelware engines, where each API backend can be crazly optimized, while I have the productivity freedom to just ask to draw my scene, with a nicely organized set of meshes, materials and combined shaders, without feeling I am doing graphics programming with two sticks.

The anti-managed bias on some Vulkan circles also doesn't help, specially when the OpenGL deprecation message keeps poping up in Vulkan related talks.

Yes, using managed languages will take some performance out of Vulkan, but guess whose's fault it is when no other API gets offered as alternative, not everyone is jumping of joy to use C for graphics programming.

And here Metal, DirectX, LibGNMN, NVN, WebGL, WebGPU take a much developer friendly attitude.

Gallium3D is a framework for building drivers, not a graphics API. The intel drivers do not use gallium3d (yet), and neither do nvidias.

They could implement OpenGL API over Vulkan, so it's just a library, no need to touch drivers.