Hacker News Reader

Politics only plays such a strong role because at the end of the day having a single API doesn't solve a real problem. It's desirable because it reduces the surface area of new things developers have to learn if they want to target all these systems. However, mostly different people work on different targets and it really just helps with learning. In terms of actual building, deploying etc it's probably best to have proprietary things that wrap themselves cleanly around the systems they are operate in.

Strong disagree as someone who spent years on a cross-platform accelerated vector graphics library in industry. Dealing with API differences and differences in tooling (Metal's tooling is far behind RenderDoc for example) took an enormous amount of my time, time that could otherwise have been spent fixing bugs and adding features.

I don't disagree you had these problems. I'm just saying the market of developers in your pool is not very big. Most people are happy just learning a single platform, chip, etc and getting a job writing code against it. I get the allure of "if only every target spoke the language I Know.. then I could target all the things.." but in practice it's not really a problem

The sheer quantity of things not even started because of the excess cost of targeting everything absolutely dwarfs the sum total of what is now built for this or that target. We have seen this dynamic play out over and over again, in the past six+ decades, going all the way back to FORTRAN.

A standard target would multiply the size of this "market" many times over, generating additional demand for implementations throughout multiple industries. Balkanization has always been a debilitating tax on everyone, not excepting "market leaders" scrapping over the artificially reduced pie. Everyone made way more money after FORTRAN than before.

if the cost is attributed to "targeting everything" as you say, then wouldn't those things just get started by targeting one thing? Neither you or I can prove there are things not invented because of this, so nothing to debate here. The reason why pcwalton spent lots of effort jumping through hoops building a vector graphics library that targets lots of platforms is because we already know that vector graphics is something we had on a single platform. It is really hard for to imagine something not being invented/created at all because there isn't a single language that can express its computation everywhere simultaneously.

That argument has been repeated over and over again, over decades, and is proven wildly off the mark the moment standardization enables the test, every time.

Strangely, the fact never prevents it being trotted out again, every time.

The only time standardization unlocks innovation is when agreement is core to the function of the system (TCP/IP, communication protocols, etc). If it's simply to create a common abstraction across similar things, then it won't unlock anything. It's simply a nice to have.

Why doesn't Apple consider their GPU to be a core function of their system, then?

Strangely, the fact still never prevents it being trotted out again, every time.

A GPU is not core to the function of modern personal computers? It's not 1990 anymore. Literally every single personal computer has a GPU. In fact it would be more apt to say that nowadays you buy a GPU that has sacrificed a small part of its transistor budget to include a CPU.

The claim seems to be that the cited phenomenon applies only when interoperability between disjoint organizations is involved. But we see its wider applicability all the time, if only because education and similar infrastructure is exactly such an interoperation.

Yes its true. Which is exactly why javascript and html gave way to a broader programmer market. This creates lots of educational content and improves the educational experience. Especially bc standards evolve slow and don’t typically break. So you can find old resources that are still useful. That being said, it doesnt create innovation. This is why you have so many web frameworks. Innovation cant truly run wild so people reorganize whats inside the box already. To get outside you must connect compute with new sensors, io, etc. and in this case standardization doesnt matter initially

If you find such innovation, let me know. We've given Apple just about 2 decades to blow us away here, and all we've got to show for it is Final Cut Pro.

Yet, every widely adopted standard leads to such an expansion of the whole market that overwhelmingly more resources become available to innovate. Thus, FORTRAN became FORTRAN II, III, IV, Fortran77, 90, driving demand for supercomputers CDC 6400, Cray, and on up. UNIX became Posix, now Linux. Bell Labs C became C++, then C++98, C++11, now C++20 and Rust. Silicon Graphics SGL became OpenGL that spawned numerous successors, and now Vulkan, which has already spawned Vulkan 1.1.

So, the "innovation" argument is always trotted out, against copious evidence. But MBAs always fall for it, and we get things like DirectX, CUDA, and Metal that invariably end up acting to stall innovation, instead.

DirectX, CUDA and Metal are the product of copious amounts of innovation themselves. What is your best guess at the missing things we don’t have today because of their stalling? Just curious what you are thinking.

Each receives nothing but the investment allocated to it by the one or, sometimes, two or three companies under contract, to address exactly the business goals of those companies and nothing else.

Lots of innovation, that is why OpenGL and Vulkan were basically copying DirectX features via extension spaghetti.

Next on the pipeline, mesh shaders.

Additionally why OpenCL only cared about anything beyond C after getting punched to the ground via C++ first alongside polyglot PTX.

Khronos innovates so much that the graduation ceremony of using their APIs is to create a self built SDK, hunting for libraries and graphic debugging tools from each card vendor.

Afterwards one is worthy to wore the ring of portable 3D mighty league.

Yes but in no way do gpus being able to talk to other gpus in a standard way is core to the function of computer equipped with a GPU. All that matters is that the GPU can be programmed in some way.

We are not talking about inter-GPU communication. Only about using a single GPU.

Right, and he is saying that interoperability would be essential only if GPUs needed to talk to each other and is inessential in the current reality.

I'm not sure what you are saying. The thread is about people disagreeing with him.

I'm surprised to hear your poor experience with Metal tooling. In my book, it was always superior to RenderDoc. For example, it got able to debug shaders way before RenderDoc started supporting this on Vulkan. It also goes above and beyond with showing your render graph, performance metrics and hints. The only problem with Metal tooling is occasional bugs, but it's not like RenderDoc is clean of them either.

My theory about Metal is that Apple wanted to own the whole stack, and controlling the API meant they could plan ahead for their own silicon. Instead of being limited to the way a standards body planned around existing silicon and ISAs, Apple gets to explicitly determine their own future.

> It does have the excuse that it was being developed before Vulkan

This is not true, Mantle was first. AMD donated the code to khronos and it became/was developed in public. Half way through Apple announced it would do its own thing and beat Vulkan to v1.0.0.

Apple might have had a v1 before Vulkan but they're still dicks for not helping build a unified standard around AMDs generous once a generation offer.

Metal isn’t just a graphics api but also becoming a CUDA alternative. It’s a very important api for Apple.

> There's mostly not a reason why we couldn't have a single API other than politics.

If you follow Apple's logic, this is totally wrong. Everything has to be integrated in order to achieve the best possible experience, and public APIs would be a bottleneck that make things inflexible for the company that tries to exploit the technology.

I don't know, I feel like you could do a few name substitutions from this 16yr old comic [1] and it would perfectly fit this situation (of course Sony becomes Apple).

[1] https://cad-comic.com/comic/doing-business/

The difference is that Apple actually does achieve some minimal base line of quality while Sony just pretends it does.

> There's no compelling reason why Web Shading Language needs to exist.

I'm pretty sure it basically doesn't. WebGPU is supporting WGSL whose #1 goal is to be "trivially convertible to SPIR-V" (https://www.w3.org/TR/WGSL/#goals). In other words, it's text SPIR-V.

It’s only talking about one way: WGSL->SPIRV, not the reverse. It also has to be trivially convertible to MSL and HLSL. So WGSL is a separate language now, most ties to SPIRV are cut off.

I agree with you about Web Shading Language not needing to exist.

But I also don't think it's the end of the world, either. Google's Tint can translate between SPIR-V/GLSL/etc -> WGSL and vice-versa pretty well.

If that's what it takes for Apple to be on board with WebGPU and we get an extension later to load SPIR-V (or some other WGSL binary form) later for optimization I'm cool with that.

Yeah, the silver lining is that the amount of effort folks have gone to in order to ensure some level of interoperability has been amazing. Khronos developers working on SPIRV-Cross, wgpu-rs folks like kvark, MoltenVK people, Wine devs, etc. are unsung heroes of the graphics industry and deserve tons of support.

Even if SPIRV input becomes available as an extension at some point, don’t expect it to be any kind of optimization. Both Tint and Naga’s IRs are close to WGSL, so parsing it is really easy and fast. Processing SPIRV’s control flow graph, images/samplers, atomics, is quite painful in comparison.

From kvark himself, big fan of your work :) Very interesting, thanks for saying this, I wouldn't have thought SPIRV->Target could be faster than or near the same speed as WGSL->Target.

I guess with compression probably being quite good, as well, there isn't much point of a SPIRV extension for download times or processing times?

You missed LibGNM and NVN.

DirectX and Metal are great with high level bindings, and much more productive shading languages, instead of "C way" that Khronos keeps pushing for.

Khronos is pushing for SPIR-V, which isn't a language but a bytecode. There are a lot of good reasons to do this: It allows innovation for shading languages to take place as anyone can build their own language and compile it down to SPIR-V, and it's much easier to parse than, say, GLSL, making it easier the proprietary drivers aren't doing something stupid.

The DirectX shading language (HLSL) and the metal shading language (MSL) could both compile down to SPIR-V, other than the occasional missing feature that's not standardized yet.

Right, SPIRV is a good format as the destination of your shader pipeline. But it can only be that on Vulkan. With other backends, SPIRV doesn’t help, and instead stands in the way.

https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html

Apple doesn't want the web to be a viable alternative to the app store. They'll continue to choose strategies that hold it back.

It's not so clear-cut, they're pouring a lot of resources into WebGPU and Safari.

This, they literally posted a TON of engineering WebGPU jobs just recently for their WebKit team.

For what it's worth, I do not believe that this is Apple's strategy. Squabbles with Khronos suffice to explain everything.

This is true, there is so much more that Safari could be capable of if it gave developers lower level hardware capabilities, but that would hurt the bottom line…