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

21–30 of 186 posts

Re: No Graphics API

#21

Post by jsheard »

m-schuetz wrote: post #19
MaximilianEmel wrote: post #12

I wonder if Valve might put out their own graphics API for SteamOS.

Valve seems to be substantially responsible for the mess that is Vulkan. They were one of its pioneers from what I heard when chatting with Vulkan people.

There's plenty of blame to go around, but if any one faction is responsible for the Vulkan mess it's the mobile GPU vendors and Khronos' willingness to compromise for their sake at every turn. Huge amounts of API surface was dedicated to accommodating limitations that only existed on mobile architectures, and earlier versions of Vulkan insisted on doing things the mobile way even if you knew your software was only ever going to run on desktop.

Thankfully later versions have added escape hatches which bypass much of that unnecessary bureaucracy, but it was grim for a while, and all that early API cruft is still there to confuse newcomers.

Re: No Graphics API

#22

Post by pjmlp »

m-schuetz wrote: post #19
MaximilianEmel wrote: post #12

I wonder if Valve might put out their own graphics API for SteamOS.

Valve seems to be substantially responsible for the mess that is Vulkan. They were one of its pioneers from what I heard when chatting with Vulkan people.

Samsung and Google also have their share, see who does most of Vulkanised talks.

Re: No Graphics API

#23

Post by alberth »

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.

Would this be analogous to NVMe?

Meaning ... SSDs initially reused IDE/SATA interfaces, which had inherent bottlenecks because those standards were designed for spinning disks.

To fully realize SSD performance, a new transport had to be built from the ground up, one that eliminated those legacy assumptions, constraints and complexities.

Re: No Graphics API

#25

Post by aarroyoc »

Impressive post, so many details. I could only understand some parts of it, but I think this article will probably be a reference for future graphics API.

I think it's fair to say that for most gamers, Vulkan/DX12 hasn't really been a net positive, the PSO problem affected many popular games and while Vulkan has been trying to improve, WebGPU is tricky as it has is roots on the first versions of Vulkan.

Perhaps it was a bad idea to go all in to a low level API that exposes many details when the hardware underneath is evolving so fast. Maybe CUDA, as the post says in some places, with its more generic computing support is the right way after all.

Re: No Graphics API

#26

Post by blakepelton »

Great post, it brings back a lot of memories. Two additional factors that designers of these APIs consider are:

* GPU virtualization (e.g., the D3D residency APIs), to allow many applications to share GPU resources (e.g., HBM).

* Undefined behavior: how easy is it for applications to accidentally or intentionally take a dependency on undefined behavior? This can make it harder to translate this new API to an even newer API in the future.

Re: No Graphics API

#27

Post by rnewme »

alberth wrote: post #23
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.

Would this be analogous to NVMe? Meaning ... SSDs initially reused IDE/SATA interfaces, which had inherent bottlenecks because those standards were designed for spinning disks. To fully realize SSD performance, a new transport had to be built from the ground up, one that eliminated those legacy assumptions, constraints and complexities.

...and introduced new ones.

Re: No Graphics API

#28

Post by mrec »

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…

Isn't this already happening to some degree? E.g. UE's Nanite uses a software rasterizer for small triangles, albeit running on the GPU via a compute shader.

Re: No Graphics API

#29

Post by ginko »

I mean sure, this should be nice and easy.

But then game/engine devs want to use the vertex shader producing a uv coordinate and a normal together with a pixel shader that only reads the uv coordinate (or neither for shadow mapping) and don't want to pay for the bandwidth of the unused vertex outputs (or the cost of calculating them).

Or they want to be able to randomly enable any other pipeline stage like tessellation or geometry and the same shader should just work without any performance overhead.

Post reply on HN