I miss the years where inspite of all its flaws, OpenGL was a non deprecated option on all the platforms. I know it left performance on the table, I know the drivers for some vendors were iffy and I know reasoning about performance across different vendors / drivers / platforms was difficult - but it worked most of the time and allowed me to have a mostly unified codebase everywhere.

You can still kind of have that experience by using ANGLE[1] as your OpenGL implementation. It lets you use the same dialect of OpenGL ES on Windows, Linux, Mac, and Android, with consistent behavior across platforms.

ANGLE is the base of the WebGL implementation in Chrome. For WebGPU, we (Google) are working on a new native library called Dawn[2] that will fill the same role that ANGLE does for WebGL. I'm personally hopeful that Dawn itself can eventually be useful as a cross platform graphics abstraction for native apps as well as web apps. There's also Mozilla's gfx-rs[3] in the same space.

[1] https://github.com/google/angle

[2] https://dawn.googlesource.com/dawn

[3] https://github.com/gfx-rs/gfx

That's nice, but it's a pretty big dependency to add.

This really. I'm still using OpenGL and it's worth so much to have an adequate truly cross platform graphics API. The gfx-hal people are doing good work in Rust for a cross platform vulkan like api, but it's not there yet.

OpenGL is STILL viable today. You can use a shared subset of ES 3.x and Desktop GL 3.x, and the amount of places where you need to if/#ifdef because of differences is vanishingly small (mostly some minor shader decls). Certainly don't need a giant library like ANGLE to do this.

We still don't know when Apple will actually remove GL from their platforms, but since the backlash will be so huge, it might be a while. And even when they do, the first step of 95% of code-bases that rely on GL will be to link in some GL on Metal emulation library. The net effect will be a slight performance drop for Apple vs other platforms. Well done Apple.

At some point switching to Vulkan (and Vulkan on Metal for Apple, or the reverse if you're an Apple centric developer) may be worth it, but for the moment the amount of apps and games that will see close to identical performance in GL and Vulkan is still huge. If you are e.g. geometry/shader/memory bound, you'll see exactly 0% speedup from API changes. You really need to be pushing significant amount of draw calls to see a difference. If you're not doing this, its worth "hanging in there" with GL to see if the post-GL landscape de-clusterfucks itself in the meantime :)

Thanks for this perspective, it is helpful. In our industry not reacting to developments of the day is often the most courageous choice one can make.

Only when "all platforms" leaves out game consoles, which never had full support for OpenGL, besides a timid attempt with GL ES 1.0 + Cg on PS2.

It's true, but for most applications, games consoles are not even a consideration. There's a mountain of programs that only target Windows, Linux, macOS, Android, and iOS or some subset thereof.

Doesn't change the fact that OpenGL was never available in all platforms, regardless how often one spreads that urban myth.

Even on Mac OS it wasn't available, rather Quickdraw 3D was the API to go to.

Had Apple been successful with their in house OS, and surely they wouldn't have cared about OpenGL.

Are you saying OpenGL wasn't on Mac OS before Mac OS X? That's not true. Apple released OpenGL for Mac OS 9 in 1999.

WWDC 1999: Mac OS 9 - A work in progress https://youtu.be/LkmSrCsKPLk?t=1360

WWDC 1999 was after NeXT's acquisition, the engine was already rolling, adopting NeXTSTEP features.

Also note that Copland did not have any OpenGL support planned.

WebGL is like that now.

> There is almost no cost to the platform developers to add new APIs

To anyone who has ever spent time working on a platform API this is deeply insulting.

> …the costs are borne by the application developers.

Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)NaCL.

> To anyone who has ever spent time working on a platform API this is deeply insulting.

I've worked on platform APIs too. Maybe "almost no cost" wasn't the right phrase, but there's certainly less cost for the platform vendor.

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

It's a tradeoff that has to be evaluated on a case-by-case basis. So far I haven't seen arguments for WSL that are compelling enough.

My critique on all of these remains largely the same since we tried doing WebCL:

-- Path 1: We do need a leap here, and that leap should be essentially unleashing GPGPU primitives (memory barriers, etc.). The web is a ~decade behind, when we have a chance to 10X+ over what regular apps do.

-- Path 2: If not, then pure conservative standards work a la webgl2. Useful, and should take care for politicking to not prevent Path 1 from happening in parallel.

It's disconcerting for, ~7 years later, the same problems to keep happening.

They have to implement the existing API or their own. The cost will be the same for both cases. For big platform vendors, almost no(extra) cost.

On the other hand, we, the ordinary developer must pay the cost of supporting N APIs on M platforms. Every APIs carelessly invented by vendors just because almost no extra cost burden us all.

Hence middleware engines, with productive high level APIs, while using every feature across all boards, without having to deal with messy extensions.

AMDN and Khronos are still fighting to get the love of CAD industry, adding back OpenGL features, because after having to create Iris Inventor like APIs in-house, they aren't keen in switching to yet another low level API.

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

I’m one of the most vehement proponents for the use of platform-specific UI toolkits here, but even I disagree with that this statement without qualification. Standards, in general, are a useful thing to have. We’ve occasionally seen (for example, in the case of application frameworks) that each platform doing their own thing has now made it so that the better experience for the user is the non-general API. But standardized interfaces (POSIX, OpenGL, JavaScript) when done right have been a boon for developers and end-users alike.

All those standards are good examples of write once, debug everywhere, implement multiple code paths tailored by bugs, OEM specific features and workarounds.

Making the end result in industrial code bases hardly much different from implementing multiple times.

This seems a somewhat ill-informed comment, since you shouldn't be thinking of something like Vulkan as a platform API in the first place. Vulkan (and most other APIs, e.g. OpenGL) is an almost entirely platform-independent API targeting modern GPUs. There are a small number of platform-dependent entry points for window system interaction and such like, but their surface area is a very small percentage of the overall API since GPUs are such complex beasts.

And it shows, given the lack of tooling versus what platform APIs offer out of the box.

Instead of a modern API, frameworks, 3D model format, IDE support for debugging shaders, we get plain old C, extensions creep, and go search yourself for basic feature like displaying text or loading textures.

Hardly an improvement on OpenGL status quo.

OK, of the criticisms of Vulkan I've heard, "it doesn't have a function for display text" is the weirdest one. I would be upset if Khronos did include a function for displaying text, because it would invariably be broken in numerous ways.

That attitude is why plenty of graphical developers rather adopt platform APIs instead, because we get the full package for anything graphics related, instead of learning to make fire with sticks.

I did my graduation thesis in OpenGL, hunting for libraries that kind of work together, and doing from scratch what every other OpenGL beginner has to go through, is no fun.

Every Vulkan book does the same, first set of chapters are tips about which libraries to hunt for.

The dark side allows for a better gratification on time to pixel, instead of rites of passage.

Something that Khronos has failed to learn with OpenGL and their Vulkan SDK proves that they didn't actually learn their lesson.

If Vulkan SDK was actually at the same level as DirectXTK, Metal Kit, 3DS SDK, PhyreEngine,GX2... maybe it would get more love from those us that rather embrace the dark side.

WebSQL wasn't a mistake.

It make an enormous amount of existing code available on the web.

It just wasn't agreed to by Firefox because it didn't have enough JS.

It wasn't agreed on because it was not standardized and most importantly, because there were no alternative implementations. SQLite is amazing but accepting a single implementation as standard is a huge dependency. I was very sad to see it getting dropped but it had to be.

The only thing that already exists that is provably web-safe is the WebGL dialect of GLSL (which no one seems to like). WebSPIR-V would be based on SPIR-V but in many ways has to be a new thing as well.

Edit: I originally said "WebGPU dialect of GLSL" which is not a thing. I meant "WebGL dialect of GLSL", which is a thing and which works ok in practice.

I don't see any way in which it won't be way more work to migrate to this proposed WSL than to get my existing SPIR-V tooling working with Web SPIR-V.

The actual functionality exposed is close enough that cross-compiling is a solvable problem. But fair point.

(On the flip side, having two syntactically very similar but actually different things can be dangerous, as it may lead devs to think some tooling works when it actually doesn't.)

Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people.

See: https://www.shadertoy.com/

It might be that browser vendors would be better at writing compilers than GPU vendors, but there were a lot of bugs in GLSL compilers. SPIR-V was introduced to be a simpler format for GPUs to ingest, letting you do the complex parsing up front on your machine (where it's easier to identify and fix problems).

The other benefit was that changes could be made to improve the usability of the shading language without having to wait on all vendors to update their compilers. If the change was just syntactic sugar, it could be made without changing the SPIR-V. It's kind of like how you don't need an operating system update to move from C++98 to C++11.

Hilariously, Apple actually considers the shift from C++98 to C++11 something that required an operating system upgrade (they purposefully shipped an ancient version of libstdc++ while disingenuously doing comparisons against only what they shipped, not what had come from upstream, for as long as they could until libc++ was reasonable, which debuted on macOS 10.7--where I will note it was horribly broken due to an LLVM optimizer bug in the specific clang build they used to compile it, so really it wasn't available until macOS 10.8--and as Apple does not believe in static linking, their SDK doesn't have a way to work around this; of course, you can, and I did--by getting the code for libc++, modifying it to use an underlying libstdc++ as the moral equivalent of libc++abi, and statically linking that, which worked great and is frankly what Apple should have done themselves during the transition period :/--it is notable that Apple didn't want people to: they really do mentally model that as an operating system upgrade, which to me is an amazing demonstration of how little they understand of the power and potential of decoupled toolchains).

> Apple does not believe in static linking, their SDK doesn't have a way to work around this

Apple isn’t alone this regard; as far as I can tell Windows does this too because they don’t commit to a stable syscall interface like Linux does. That being said, you may find Apple’s official stance on statically linking your binaries amusing: https://developer.apple.com/library/archive/qa/qa1118/_index...

In general, Apple links a lot of things to their OS releases: while their toolchains are distributed separately they’re practically tied to one or two major OSes unless you engage in hacks to make them continue working. And the languages which they exercise significant control over (namely Swift and Objective-C) are often tied to OS versions.

Browser vendors are a lot better at writing compilers than GPU vendors. Also there are fewer different browser engines than different GPU drivers so that also helps.

It strangely hasn’t been seriously considered but it might not be a bad option (though it may need a more rigorous reformilation of the spec).

You can always just cross compile your SPIR-V to GLSL or something. People have been cross compiling between HLSL and GLSL for ages, it's a solved problem even if there are sharp edges.

There is no WebGPU dialect of GLSL, only a SPIR-V execution environment for WebGPU. Lnaguages in themselves aren't "safe" or "unsafe", their implementations are.

Also please stop trying to influence a technical debate in a standardization group by putting blog posts on top of Hacker News.

Sorry, I meant WebGL, simply mistyped.

As far as posting blog posts, we think this is just as fair as the Chrome team's communication about their own WebGPU implementation, which included a public demo and sessions at Google I/O which were widely reported.

As for the post getting upvoted to the top of Hacker News, that's the community's choice, not ours. The initial poster wasn't even an Apple person (afaik). If you are insinuating some kind of vote manipulation then that is inaccurate.

You're absolutely wrong here. A language must specify its semantics. Those semantics describe the safety properties of that language.

I rather care about middleware that takes advantage of best hardware integration in each platform, instead of bare bones APIs full of endless extensions, which are only portable in theory, with "portable code" full of OEM specific code paths.

What are you working on? I have no experience in graphics development, only a cursory familiarity with some concepts, but can I help? Typical Frontend has kind of become boring now that everything is abstracted and the harder stuff mostly resides in graphics or on the edge. Just haven't really found a way to make that change yet.

> Please, everyone, just use something that already exists.

Says one "who is currently knee-deep in papering over platform incompatibilities", instead of using one of the solutions that do it for you.

I wasn't referring to pathfinder_gpu. :)

(I didn't downvote you.)