Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No Graphics API

sebastianaaltonen.com

Post reply on HN
Print view View original

141–150 of 186 posts

Re: No Graphics API

#141

Post by fngjdflmdflg »

Joker_vD wrote: post #118
Antibabelic wrote: post #109

Earlier quoted context omitted.

"Offtop" is not a word. It's not in any English dictionary I could find and doesn't appear in any published literature. Matthew 7:3 "And why beholdest thou the mote that is in thy brother's eye, but considerest not the beam that is in thine own eye?"

Oh, it's a transliteration of Russian "офтоп", which itself started as a borrowing of "off-topic" from English (but as a noun instead of an adjective/stative) and then went some natural linguistic developments, namely loss of a hyphen and degemination, surface analysis of the trailing "-ic" as Russian suffix "-ик" [0], and its subsequent removal to obtain the supposed "original, non-derived" form. [0] https://en.wikt…

>subsequent removal to obtain the supposed "original, non-derived" form

Also called a "back-formation". FWIF I don't think the existence of corrupted words automatically justifies more corruptions nor does the fact that it is a corruption automatically invalidate it. When language among a group evolves, everyone speaking that language is affected, which is why written language reads pretty differently looking back every 50 years or so, in both formal and informal writing. Therefore language changes should have buy-in from all users.

Re: No Graphics API

#142

Post by jama211 »

stevage wrote: post #53
opminion wrote: post #15

The article is missing this motivation paragraph, taken from the blog index: > Graphics APIs and shader languages have significantly increased in complexity over the past decade. It’s time to start discussing how to strip down the abstractions to simplify development, improve performance, and prepare for future GPU workloads.

Thanks, I had trouble figuring out what the article was about, lost in all the "here's how I used AI and had the article screened by industry insiders".

You only read two paragraphs in then?

Re: No Graphics API

#143

Post by fngjdflmdflg »

I think this almost has to be the future if most compute development goes to AI in the next decade or so, beyond the fact that the proposed API is much cleaner. Vendors will stop caring about maintaining complex fixed function hardware and drivers for increasingly complex graphics APIs when they can get 3x the return from AI without losing any potential sales, especially in the current day where compute seems to be more supply limited. Game engines can (and I assume already do) benefit from general purpose compute anyway for things like physics, and even for things that it wouldn't matter in itself for performance or would be slower, doing more on the GPU can be faster if your data is already on the GPU, which becomes more true the more things are done on the GPU. And as the author says, it would be great to have an open source equivalent to CUDA's ecosystem that could be leveraged by games in a cross platform way.

Re: No Graphics API

#144

Post by m-schuetz »

CupricTea wrote: post #135
m-schuetz wrote: post #96

Earlier quoted context omitted.

Man, how I wish WebGPU didn't go all-in on legacy Vulkan API model, and instead find a leaner approach to do the same thing. Even Vulkan stopped doing pointless boilerplate like bindings and pipelines. Ditching vertex attrib bindings and going for programmable vertex fetching would have been nice. WebGPU could have also introduced Cuda's simple launch model for graphics APIs. Instead of all that insane binding boiler…

>Man, how I wish WebGPU didn't go all-in on legacy Vulkan API model WebGPU doesn't talk to the GPU directly. It requires Vulkan/D3D/Metal underneath to actually implement itself. >Even Vulkan stopped doing pointless boilerplate like bindings and pipelines. Vulkan did no such thing. As of today (Vulkan 1.4) they added VK_KHR_dynamic_rendering to core and added the VK_EXT_shader_object extension, which are not required…

> WebGPU doesn't talk to the GPU directly. It requires Vulkan/D3D/Metal underneath to actually implement itself.

So does WebGL and it's doing perfectly fine without pipelines. They were never necessary. Since WebGL can do without pipelines, WebGPU can too. Backends can implement via pipelines, or they can go for the modern route and ignore them.

They are an artificial problem that Vulkan created and WebGPU mistakenly adopted, and which are now being phased out. Some devices may refuse to implement pipeline-free drivers, which is okay. I will happily ignore them. Let's move on into the 21st century without that design mistake, and let legacy devices and companies that refuse to adapt die in dignity. But let's not let them hold back everyone else.

Re: No Graphics API

#145

Post by pjmlp »

flohofwoe wrote: post #113
kllrnohj wrote: post #60

Earlier quoted context omitted.

Only if you're ignoring mobile entirely. One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs.

> One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs. In hindsight it really would have been better to have a separate VulkanES which is specialized for mobile GPUs.

Apparently in many Android devices it is still better to target OpenGL ES than Vulkan due to driver quality, outside Samsung and Google brands.

Re: No Graphics API

#146

Post by pjmlp »

kllrnohj wrote: post #132
deliciousturkey wrote: post #116

Earlier quoted context omitted.

Switch has its own API. The GPU also doesn't have limitations you'd associate with "mobile". In terms of architecture, it's a full desktop GPU with desktop-class features.

well, it's a desktop GPU with desktop-class features from 2014 which makes it quite outdated relative to current mobile GPUs. The just released Switch 2 uses an Ampere-based GPU, which means it's desktop-class for 2020 (RTX 3xxx series), which is nothing to scoff about but "desktop-class features" is a rapidly moving target and the Switch ends up being a lot closer to mobile than it does to desktop since it's always…

Still beats the design of all Web 3D APIs, and has much better development tooling, let that sink in how behind they are.

Re: No Graphics API

#147

Post by dundarious »

newpavlov wrote: post #140
dundarious wrote: post #138

I see this as an expression of the same underlying complaint as Casey Muratori's 30 Million Line Problem: https://caseymuratori.com/blog_0031 Casey argues for ISAs for hardware, including GPUs, instead of heavy drivers. TFA argues for a graphics API surface that is so lean precisely because it fundamentally boils down to a simple and small set of primitives (mapping memory, simple barriers, etc.) that are basically e…

I generally agree with this opinion and would love to see a proper well documented low-level API for working with GPU. But it would probably result in different "GPU ISAs" for different vendors and maybe even for different GPU generations from one vendor. The bloated firmwares and drivers operating on a higher abstraction level allow to hide a lot of internal implementation details from end users. In such world most…

I wouldn't be so sure, as if we analogize to x86(_64), the ISA is stable and used by many vendors, but the underlying microarchitecture and caching model, etc., are free reign for impl-specific work.

Re: No Graphics API

#148

Post by pjmlp »

m-schuetz wrote: post #96
jdashg wrote: post #46

And the GPU API cycle of life and death continues! I was an only-half-joking champion of ditching vertex attrib bindings when we were drafting WebGPU and WGSL, because it's a really nice simplification, but it was felt that would be too much of a departure from existing APIs. (Spending too many of our "Innovation Tokens" on something that would cause dev friction in the beginning) In WGSL we tried (for a while?) to b…

Man, how I wish WebGPU didn't go all-in on legacy Vulkan API model, and instead find a leaner approach to do the same thing. Even Vulkan stopped doing pointless boilerplate like bindings and pipelines. Ditching vertex attrib bindings and going for programmable vertex fetching would have been nice. WebGPU could have also introduced Cuda's simple launch model for graphics APIs. Instead of all that insane binding boiler…

My biggest issues with WebGPU are, yet another shading language, and after 15 years, browser developers don't care one second for debugging tools.

It is either pixel debugging, or trying to replicate in native code for proper tooling.

Re: No Graphics API

#149

Post by m-schuetz »

pjmlp wrote: post #148
m-schuetz wrote: post #96

Earlier quoted context omitted.

Man, how I wish WebGPU didn't go all-in on legacy Vulkan API model, and instead find a leaner approach to do the same thing. Even Vulkan stopped doing pointless boilerplate like bindings and pipelines. Ditching vertex attrib bindings and going for programmable vertex fetching would have been nice. WebGPU could have also introduced Cuda's simple launch model for graphics APIs. Instead of all that insane binding boiler…

My biggest issues with WebGPU are, yet another shading language, and after 15 years, browser developers don't care one second for debugging tools. It is either pixel debugging, or trying to replicate in native code for proper tooling.

Ironically, WebGPU was way more powerful about 5 years ago before WGSL was made mandatory. Back then you could just use any Spirv with all sorts of extensions, including stuff like 64bit types and atomics.

Then wgsl came and crippled WebGPU.

Re: No Graphics API

#150

Post by qingcharles »

webdevver wrote: post #127
qingcharles wrote: post #74

I started my career writing software 3D renderers before switching to Direct3D in the later 90s. What I wonder is if all of this is going to just get completely washed away and made totally redundant by the incoming flood of hallucinated game rendering? Will it be possible to hallucinate the frame of a game at a similar speed to rendering it with a mesh and textures? We're already seeing the hybrid version of this wh…

reminds me of this remark made by Carmack on hidden surface removal https://www.youtube.com/watch?v=P6UKhR0T6cs&t=2315s > "research from the 70s especially, there was tons of work going on on hidden surface removal, these clever different algorithmic ways - today we just kill it with a depth buffer. We just throw megabytes and megabytes of memory and the problem gets solved much much easier." ofcourse "megabytes" of…

Agree. If you look at the GPU in an iPhone 17 and compare to the desktop GPU I had in 1998, the difference is startling.

Voodoo in 1998 could render about 3m poly/sec on a Utah teapot, which was absurd number at the time, where I was coming from software renderers that were considered amazing at 100K/sec.

A19 Pro GPU could do about 5bn/sec at about 4X the resolution. And it fits in your pocket. And runs off a tiny battery. Which also powers the screen.

25 years from now a 5090 GPU will be laughably bad. I have no idea how fast we'll be able to hallucinate entire scenes, but my guess is that it'll be above 60fps.

Post reply on HN