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

41–50 of 186 posts

Re: No Graphics API

#41

Post by flohofwoe »

wbobeirne wrote: post #39
flohofwoe wrote: post #11

Earlier quoted context omitted.

It's mostly not about performance, but about getting rid of legacy cruft that still exists in modern 3D APIs to support older GPU architectures.

Getting rid of cruft isn't really a goal in and of itself, it's a goal in service of other goals. If it's not about performance, what else would be accomplished?

A simplified API means higher programmer productivity, higher robustness, simplified debugging and testing, and also less internal complexity in the driver. All this together may also result in slightly higher performance, but it's not the main goal. You might gain a couple hundred microseconds per frame as a side effect of the simpler code, but if your use case already perfectly fits the 'modern subset' of Vulkan or D3D12, the performance gains will be deep in 'diminishing returns area' and hardly noticeable in the frame rate. It's mostly about secondary effects by making the programmer's life easier on both sides of the API.

The cost/compromise is dropping support for outdated GPUs.

Re: No Graphics API

#42

Post by efilife »

gmueckl wrote: post #35
pjmlp wrote: post #17

I have followed Sebastian Aaltonen's work for quite a while now, so maybe I am a bit biased, this is however a great article. I also think that the way forward is to go back to software rendering, however this time around those algorithms and data structures are actually hardware accelerated as he points out. Note that this is an ongoing trend on VFX industry already, about 5 years ago OTOY ported their OctaneRender…

There are tons of places within the GPU where dedicated fixed function hardware provides massive speedups within the relevant pipelines (rasterization, raytracing). The different shader types are designed to fit inbetween those stages. Abandoning this hardware would lead to a massive performance regression.

Offtop, but sorry, I can't resist. "Inbetween" is not a word. I started seeing many people having trouble with prepositions lately, for some unknown reason.

> “Inbetween” is never written as one word. If you have seen it written in this way before, it is a simple typo or misspelling. You should not use it in this way because it is not grammatically correct as the noun phrase or the adjective form. https://grammarhow.com/in-between-in-between-or-inbetween/

Re: No Graphics API

#43

Post by vegabook »

ironically, explaining that "we need a simpler API" takes a dense 69-page technical missive that would make the Kronos Vulkan tutorial blush.

Re: No Graphics API

#44

Post by dist-epoch »

efilife wrote: post #42
gmueckl wrote: post #35

Earlier quoted context omitted.

There are tons of places within the GPU where dedicated fixed function hardware provides massive speedups within the relevant pipelines (rasterization, raytracing). The different shader types are designed to fit inbetween those stages. Abandoning this hardware would lead to a massive performance regression.

Offtop, but sorry, I can't resist. "Inbetween" is not a word. I started seeing many people having trouble with prepositions lately, for some unknown reason. > “Inbetween” is never written as one word. If you have seen it written in this way before, it is a simple typo or misspelling. You should not use it in this way because it is not grammatically correct as the noun phrase or the adjective form. https://grammarhow.…

If enough people use it, it will become correct. This is how language evolves. BTW, there is no "official English language specification".

And linguists think it would be a bad idea to have one:

https://archive.nytimes.com/opinionator.blogs.nytimes.com/20...

Re: No Graphics API

#45

Post by mkoubaa »

vegabook wrote: post #43

ironically, explaining that "we need a simpler API" takes a dense 69-page technical missive that would make the Kronos Vulkan tutorial blush.

I don't understand why you think this is ironic

Re: No Graphics API

#46

Post by jdashg »

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 build language features as "sugar" when we could. You don't have to guess what order or scope a `for` loop uses when we just spec how it desugars into a simpler, more explicit (but more verbose) core form/dialect of the language.

That said, this powerpoint-driven-development flex knocks this back a whole seriousness and earnestness tier and a half: > My prototype API fits in one screen: 150 lines of code. The blog post is titled “No Graphics API”. That’s obviously an impossible goal today, but we got close enough. WebGPU has a smaller feature set and features a ~2700 line API (Emscripten C header).

Try to zoom out on the API and fit those *160* lines on one screen! My browser gives up at 30%, and I am still only seeing 127. This is just dishonesty, and we do not need more of this kind of puffery in the world.

And yeah, it's shorter because it is a toy PoC, even if one I enjoyed seeing someone else's take on it. Among other things, the author pretty dishonestly elides the number of lines the enums would take up. (A texture/data format enum on one line? That's one whole additional Pinocchio right there!)

I took WebGPU.webidl and did a quick pass through removing some of the biggest misses of this API (queries, timers, device loss, errors in general, shader introspection, feature detection) and some of the irrelevant parts (anything touching canvas, external textures), and immediately got it down to 241 declarations.

This kind of dishonest puffery holds back an otherwise interesting article.

Re: No Graphics API

#47

Post by formerly_proven »

gmueckl wrote: post #35
pjmlp wrote: post #17

I have followed Sebastian Aaltonen's work for quite a while now, so maybe I am a bit biased, this is however a great article. I also think that the way forward is to go back to software rendering, however this time around those algorithms and data structures are actually hardware accelerated as he points out. Note that this is an ongoing trend on VFX industry already, about 5 years ago OTOY ported their OctaneRender…

There are tons of places within the GPU where dedicated fixed function hardware provides massive speedups within the relevant pipelines (rasterization, raytracing). The different shader types are designed to fit inbetween those stages. Abandoning this hardware would lead to a massive performance regression.

Just consider the sheer number of computations offloaded to TMUs. Shaders would already do nothing but interpolate texels if you removed them.

Re: No Graphics API

#48

Post by wg0 »

Very well written but I can't understand much of this article.

What would be one good primer to be able to comprehend all the design issues raised?

Re: No Graphics API

#49

Post by xyzsparetimexyz »

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…

Who cares about dev friction in the beginning? That was a bad choice.

Re: No Graphics API

#50

Post by reactordev »

djmips wrote: post #36
reactordev wrote: post #10

I miss Mantle. It had its quirks but you felt as if you were literally programming hardware using a pretty straight forward API. The most fun I’ve had programming was for the Xbox 360.

You know what else is good like that? The Switch graphics API - designed by Nvidia and Nintendo. Easily the most straightforward of the console graphics APIs

Yes but it’s so underpowered. I want RTX 5090 performance with 16 cores.
Post reply on HN