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

131–140 of 186 posts

Re: No Graphics API

#131

Post by pjmlp »

kllrnohj wrote: post #60
jsheard wrote: post #57

Earlier quoted context omitted.

Those requirements more or less line up with the introduction of hardware raytracing, and some major titles are already treating that as a hard requirement, like the recent Doom and Indiana Jones games.

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.

It is not unified, when the first thing an application has to do is to find out if their set of extension spaghetti is available on the device.

Re: No Graphics API

#132

Post by kllrnohj »

deliciousturkey wrote: post #116
Groxx wrote: post #78

Earlier quoted context omitted.

would it also apply to stuff like the Switch, and relatively high-end "mobile" gaming in general? (I'm not sure what those chips actually look like tho) there are also some arm laptops that just run Qualcomm chips, the same as some phones (tablets with a keyboard, basically, but a bit more "PC"-like due to running Windows). AFAICT the fusion seems likely to be an accurate prediction.

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 launching with ~2 generations old GPUs.

Re: No Graphics API

#133

Post by bullen »

theandrewbailey wrote: post #126
bullen wrote: post #122

Personally I'm staying with OpenGL (ES) 3 for eternity. VAO is the last feature I was missing prior. Also the other cores will do useful gameplay work so one CPU core for the GPU is ok. 4 CPU cores is also enough for eternity. 1GB shared RAM/VRAM too. Let's build something good on top of the hardware/OSes/APIs/languages we have now? 3588/linux/OpenGL/C+Java specifically! Hardware has permanently peaked in many ways,…

> Also the other cores will do useful gameplay work so one CPU core for the GPU is ok. In the before times, upgrading CPU meant eveything runs faster. Who didn't like that? Today, we need code that infinitely scales CPU cores for that to remain true. 16 thread CPUs have been around for a long time; I'd like my software to make the most of them. When we have 480+Hz monitors, we will probably need more than 1 CPU core…

I'm 60Hz for life.

Maybe 120Hz if they come in 4:3/5:4 with matte low res panel.

But that's enough for VR which needs 2x because two eyes.

So progress ends there.

16 cores can't share memory well.

Also 15W is peak because more is hard to passively cool in a small space. So 120Hz x 2 eyes at ~1080 is limit what we can do anyways... with $1/KWh!

The limits are physical.

Re: No Graphics API

#134

Post by m-schuetz »

qiine wrote: post #128
aarroyoc wrote: post #25

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 wa…

yeah.. let's make nvidia control more things..

Problem is that NVIDIA literally makes the only sane graphics/compute APIs. And part of it is to make the API accessible, not needlessly overengineered. Either the other vendors start to step up their game, or they'll continue to lose.

Re: No Graphics API

#135

Post by CupricTea »

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…

>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 to be supported and must be queried for before using. The former gets rid of render pass objects and framebuffer objects in favor of vkCmdBeginRendering(), and WebGPU already abstracts those two away so you don't see or deal with them. The latter gets rid of monolithic pipeline objects.

Many mobile GPUs still do not support VK_KHR_dynamic_rendering or VK_EXT_shader_object. Even my very own Samsung Galaxy S24 Ultra[1] doesn't support shaderObject.

Vulkan did not get rid of pipeline objects, they added extensions for modern desktop GPUs that didn't need them. Even modern mobile GPUs still need them, and WebGPU isn't going to fragment their API to wall off mobile users.

[1] https://vulkan.gpuinfo.org/displayreport.php?id=44583

Re: No Graphics API

#136

Post by dragonwriter »

mikestorrent wrote: post #99
efilife wrote: post #42

Earlier quoted context omitted.

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.…

Surely you mean "I've started seeing..." rather than "I started seeing..."?

Either the present perfect that you suggest or the past perfect originally presented is correct, and the denotation is basically identical. The connotation is slightly different, as the past perfect puts more emphasis on the "started...lately" and the emergent nature of the phenomenon, and the present perfect on the ongoing state of what was started, but there’s no giant difference.

Re: No Graphics API

#137

Post by zbendefy »

>The user writes the data to CPU mapped GPU memory first and then issues a copy command, which transforms the data to optimal compressed format.

Wouldnt this mean double gpu memory usage for uploading a potentially large image? (Even if just for the time the copy is finished)

Vulkan lets the user copy from cpu (host_visible) memory to gpu (device_local) memory without an intermediate gpu buffer, afaik there is no double vram usage there but i might be wrong on that.

Great article btw. I hope something comes out of this!

Re: No Graphics API

#138

Post by dundarious »

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 equivalent to a simple ISA.

If a stable ISA was a requirement, I believe we would have converged on these simpler capabilities ahead of time, as a matter of necessity. However, I am not a graphics programmer, so I just offer this as an intellectual provocation to drive conversation.

Re: No Graphics API

#139

Post by aj_hackman »

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…

What happens when you want to do something very new, or very specific?

Re: No Graphics API

#140

Post by newpavlov »

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 of software would still probably use something like Vulkan/DX/WebGPU to abstract over such ISAs, like we use today Java/JavaScript/Python to "abstract" over CPU ISA. And we also likely to have an NVIDIA monopoly similar to x86.

Post reply on HN