4 ms·
We don't want a standard. One size fits all doesn't work for customized hardware, as OpenGL amply demonstrated, which is why it's going away. OpenGL started dy
by glitchc 5y ago
We don't want a standard.
One size fits all doesn't work for customized hardware, as OpenGL amply demonstrated, which is why it's going away. OpenGL started dying the day NVidia introduced the GeForce series with the T&L engine. That was followed by shaders, antialiasing, anisotropic filtering and now raytracing and DLSS, not to mention innovations on the compute side and GSync/Freesync implementations. Any kind of standard acts as a bottleneck for new hardware. It's too slow to adapt to new features because it requires review and ratification, and then of course, an abstraction layer is needed to support hardware missing those features. This adds complexity. Standardized APIs are a dead-end, just like standardized CPU ISAs are a dead-end. They are trying to solve the same problem in a wrong-headed fashion.
Apple's hardware is completely different from NVidia. It makes sense to have a completely different API to fully leverage the silicon.
- dathinab 5y ago> as OpenGL amply demonstrated Not really, OpenGL had/has many problems but having a standardized interface isn't one of them (I mean one problem is the inconsistency between which extensions are available and many extensions being (or at least starting of as) somewhat Vendor specific in practice...) Sure for technological advancement we will have vendor specific code and you could say we want it. BUT most applications do not need it. Even many games don't need it. Weather most applications and any non-"AAA"-style games they often want a easy way to have reasonable well working graphics which also continue to work. Sure with such a hypothetical API the "standardized" way will be updated with new features and APIs from time to time and maybe some old features will be deprecated and emulated instead of having native hardware support but due to improvements in hardware software written "back-then" would still work. WebGPU seems to go in the right direction but Apple is messing it up again, but then "works in the Web everywhere but Apple" is something I'm already getting used to. > It's too slow to adapt to new features because it Most software just wants a frequently updated stable core set of feature which get adapted after they had been available in non standardized APIs for a while. > standardized CPU ISAs Except that ALL ISAs today are standarized, sure with extensions but the part most people use is standardized with each ISA. Weather that's ARM, x86, RISC-V, etc. Standards are what compiler makers and operating system designers rely on when it comes to designing the "generic", "general purpose parts" of their software. I mean hardly anyone would be using e.g. RISC-V if there wouldn't be a standard about how the most "core" instructions are handled. > It makes sense to have a completely different For native state of the art highly customized applications, yes. For the rest. No. It's just pain and a lot of additional development cost, and companies hate cost.
- miltondts 5y agoAnd yet, look at x86. Still going strong after 40 years. There is absolutely no reason we could not have a standard instruction set for GPUs. OpenGL is just the wrong abstraction. Same for Vulkan.
- glitchc 5y agoThe x86 ISA led to stagnation in the CPU space. Notice how an entirely new architecture (ARM) required a new ISA to fully leverage its capabilities. RISC-V is another example. A good analogy for this is the language and mind relationship. The mind shapes the language just as much as the language shapes the mind.
- fulafel 5y agoIt's not really even x86, it's the defacto C processor & machine model, and sw ecosystem. ARM works with the same sw stack as x86 because of this.