Hacker News Reader

Comment by esperent | Hacker News Reader

> So at some point, the engine stopped working on macOS. Mostly because Apple doesn’t want people to use OpenGL, so they’re starving their drivers from development

As a graphics developer, all I can say is... sigh. Apple has fought against open standards in graphics. They never overtly move against open standards (that I'm aware of) instead they use their dominant platform and refuse to or drag their heels in implementing support for open APIs.

Even though there's a new era of cross platform graphics APIs in Metal, WebGPU, and Vulkan, the fight has now moved onto formats, as everyone except Apple work towards open formats like WebP, glTF, basis universal (fortunately they can't avoid that last one), while Apple announces they'll use USDZ instead, or not add support for WebP.

View on HN

If you want to implement an OpenFX [1] effect properly you have to write its core four times:

- A CUDA implementation, if the host uses CUDA

- A Metal implementation, for Apple

- An OpenCL implementation

- A fallback CPU-based implementation

- You don't need a DirectCompute implementation, because thankfully no one is idiotic enough to use it.

- You don't need a Vulkan implementation, because no one is doing compute on Vulkan (afaik).

The state of graphics and compute APIs is utter insanity. Especially Apple can go fuck off and die with their extremely moronic move of introducing OpenCL as an open standard in '09 and then presenting Metal as their closed API in '14, moving against OpenCL, OpenGL and Vulkan. nVidia at least has the excuse they were first to market with CUDA (and it's easier to program), and they stuck to it.

[1] THE standard for video effects, think "VST, but better and for video".

> The state of graphics and compute APIs is utter insanity.

It looks like Vulkan is going to be the best-supported common platform for compute, at least for modern hardware. They need compute in the standard to support the core graphics use case anyway, so we might as well use that same support for general-purpose tasks. On Apple platforms, MoltenVk can implement Vulkan support on top of Metal

Yes, a common GPU compute platform would be great! Even if Apple isn't going to support it being able to handle all of it in Vulkan would be nice. Maybe OpenCL can be implemented on top of that.

That would be SYSCL with pluggable backends, as they also decided to move beyond OpenCL.

Because Khronos did not want to move OpenCL beyond an anemic C API, it was only the beating taken from CUDA that made them come up with SPIR, and for what OpenCL 3.0 is the admission of defeat.

By the way, Google also completely ignored OpenCL and came up with its own Renderscript dialect instead.

Have you seen this? http://diligentgraphics.com/diligent-engine/

I have not tested on Apple, but I did on ARM Linux. Their HLSL to GLES GLSL translation worked OK for my purposes. In the documentation they say they support most of them for both graphics and compute, VK and Metal included.

OpenCL was also killed off by fractured support among vendors, especially nVidia who wanted to push CUDA. Now arguably CUDA is the better API/platform but so too is Metal versus OpenCL

WebGPU has compute I believe (or hopefully will) so could theoretically act as a good common API that isn’t controlled by a single vendors whims

AMD and Intel also don't have much love for it, as they rather push their own stacks that build on top of it, or complement it in some way.

USD is not proprietary by any means. Nor is it created by Apple https://graphics.pixar.com/usd/docs/index.html

It’s an open source project by Pixar, adopted by large parts of the film industry and seeing adoption by both Unreal and Unity as well.

It’s IMHO a more comprehensive format than gltf , with the big downside being that it’s not supported by the web. However if you join the community, you can see that many big industry players are very involved with it right now.

WebP is a pretty terrible standard, all things considered, and I have very low technical confidence in JPEG XL from the same team. USDZ is also pretty different from glTF; the former is a scene description that includes things like lights and composition, while the latter is strictly model interchange. Originally designed as a transmission format until people realized it wasn't well suited for that.

How is USDZ for bones and skinning? I discovered the hard way what a mess COLLADA is, and I feel like there must be a better format out there.

glTF is a far better format than Collada and works well for every skeletal animations I've thrown at it. I use 3DS Max, export to FBX, then use the FBX2GLTF command line tool. Works seamlessly.

USD (Usdz is one of the supported extensions) supports skeletal animation, linear blend skinning and blend shapes in the default UsdSkel implementation. Additionally it’s an extensible format , so you can plug in other implementations as needed

Edit: to explain what I mean by supported extensions in case it comes up. USD is the format/library. It can be represented in three forms. USDA for ASCII, usdc for binary and usdz is a zipped bundle of the other two including any asset dependencies like textures, audio or other referenced usd files

Fair point about USDZ and glTF. I'm thinking about this from a web developer's point of view which may skew my perspective. USDZ is unusable on the web and probably will remain that way since you need to use an SDK to read the files unless someone can work some wasm magic.

glTF is a full scene exchange format, however, I deal with glTF files on a daily basis and the overwhelming majority contain only models and animation.

A format that only has taken off thanks to Microsoft contributions with glTF 2.0.

JPEG XL isn't from the same team as WebP 2.0 and arguably AVIF is. It's a combination of the team behind Brotli/Guetzli/Brunsli and Jon Sneyes, inventor of FLIF.

JPEG XL is simple enough to be written cleanly and largely from scratch, instead of being based on a fork of the crusty VP8 codebase.

There's system level support for WebP in Mac Big Sur. Also Safari 14 supports it.

I don't like it because WebP doesn't add anything else than better compression compared to PNG and JPEG. AVIF or JPEG XL bring HDR support, so Apple should have adopted one of them. Even Google is planning WebP 2.0 because they noticed that WebP isn't enough: https://www.youtube.com/watch?v=zogxpP2lm-o

WebP does add something more than better compression (unless you can live with enormous PNGs): efficient compression of lossless photographs, lossy diagrams and photographs with alpha channels.

WebP also has an unfortunately low maximum image resolution. I was trying to convert some webcomics pngs to lossy WebP for reading offline, and couldn't because the images were simply too tall to save in WebP format without resizing/cropping.

In what concerns Android, Google would could have done better for WebP adoption than just dump a sample into Github and hope for the best.

https://github.com/android/ndk-samples/tree/master/webp

Metal is not cross platform nor open.

You will laugh, but Apple started to call “cross platform” things that are used or run on more than one of their product. So cross platform between iOS, macOS, Apple TV OS(?), watchOS.

Which is correct, it is neither the same OS or hardware.

Technically correct, the best type of correct (for a marketing team).

Microsoft does that too. It's infuriating.

But all of those run Darwin, so for something like a graphics API that has nothing to do with GUIs and whatnot, the "platform" for all of those is the same.

Says someone that never read Apple documentation or iDevice literature regarding system programming on Apple platforms.

You can start by reading the Mac OS X Internals, followed by Mac OS X and iOS Internals: To the Apple's Core.

Then hop over to Apple's archive, https://developer.apple.com/library/archive/navigation/

Fair enough :)

It is "cross-platform" in the same way Direct3D is.

It is neither the same OS or hardware, so it looks cross platform to me.

In this vein and previously discussed on HN[1], but there is a weird DX3D bridge in Linux that is available on WSL2. Still not "cross-platform" and seems to mostly exist to support ML workloads for Windows users.

1] https://news.ycombinator.com/item?id=23241040

You are completely right, I shouldn't have included that in the list above.

Stop using buggy proprietary system, especially if you are a developer. It is something like Internet Explorer or Windows several years ago.

Neither Metal nor USDZ is buggy nor something like undesired software, though. On the contrary, both are exemplar and well-performing propositions.

Metal is extremely buggy if you're pushing the state of the art. Patrick Walton has run into a number of very serious driver bugs in porting Pathfinder to Metal (he can reliably panic the kernel just by running shader code), and I've seen some as well, though today I'm working in Vulkan.

I'm hopeful for WebGPU in the future, not just for its features and expected cross-platform support, but because I expect a pretty thorough test suite to emerge, holding developers' feet to the fire to make their drivers actually work.

I find the use of "extremely" to be extreme here or too forgiving of problems that arise while using other APIs. There are all kinds of state of the art algorithms implemented on top of Metal. But anything improper can easily switch off GPUs, you can even do that with CUDA.

That's fair, I've certainly also had problems with Vulkan drivers from other vendors. So I'm not saying it's more buggy than other GPU platforms, but it is buggy, and it is more buggy than we expect of CPU-based language toolchains and runtimes.

Unfortunately, that's the situation. Though in the last couple of years, there is a noticeable increase in tooling on all fronts.

Because one of the top complaints is how Vulkan is found lacking versus proprietary API SDKs, even with what LunarG provides to Khronos.

WebGPU is going to be yet another layer to blindly debug without vendors graphical debugging tools support.

Maybe those that enjoy outputting pixels or debugging messages will be fine with it.

That's not possible, because the situation we have today is that proprietary APIs (D3D, Metal, CUDA) are pretty stable, whereas open APIs (OpenGL, Vulkan, OpenCL) are buggy or unsupported.

Because Khronos just outputs piles of paper and expects partners to do the necessary, while proprietary APIs provide full stack solutions with graphical tooling.

They do heavily invest in WebGPU, which is an open standard for a portable GPU API.

An open standard heavily influenced by a combination of Apple's whims and licensing disputes with standards bodies :-)

Then it is fine, that is how design by committee works, be it at ISO, ECMA, Open Group, Khronos, W3,....

>As a graphics developer, all I can say is... sigh. Apple has fought against open standards in graphics.

Wasn't Apple the first big adopter of OpenGL? Windows had proprietary standards, Apple had OpenGL.

Sure, now they move to Metal, but it's not entirely accurate to say that "Apple has fought against open standards in graphics" generally...

No, they were into QuickDraw 3D, OpenGL came into the picture via NeXT acquisition.

Even on mobile, probably unknown in US, but Symbian and J2ME were the big motivation for OpenGL ES on mobiles, with N95 being the first handset with proper hardware acceleration.

>No, they were into QuickDraw 3D, OpenGL came into the picture via NeXT acquisition.

Well, yeah, and the Apple II used Wozniak's quirky graphics mode. But I meant the OS X era Apple, you're going back a bit...

Had Copland not failed, OpenGL would never been part of Apple's history.

As usual, companies at the edge of bankruptcy tend to be a bit more "open".

> Windows had proprietary standards, Apple had OpenGL.

Repeating the same nonsense over and over again still doesn't make it true.

Windows always had full support for every graphics API - be it proprietary (like Direct3D) or open (like OpenGL).

The difference between Apple and Microsoft was that Apple controlled access to the API, that's why you were stuck with outdated OGL versions on MacOS and can probably say goodbye to OGL entirely on their future Apple Silicon products.

Microsoft on the other hand simply stopped providing anything but a OpenGL 1.2 implementation, while leaving API support to the hardware vendors via drivers. This happened all the way back in Windows 95 already, which is why some vendors provided their own APIs (remember GLIDE?), while others shipped "MiniGL" drivers just for Quake.

Microsoft never prevented drivers from providing graphics APIs or applications from using them and redirected OpenGL calls to the hardware driver when available.

Yes I remember Glide, it was a MS-DOS based API and happend before DirectX had any proper relevance, just like miniGL.

OpenGL originally came from SGI.

Reply on news.ycombinator.com