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

91–100 of 186 posts

Re: No Graphics API

#91

Post by ehaliewicz2 »

bogwog wrote: post #73
Bengalilol wrote: post #30

After reading this article, I feel like I've witnessed a historic moment.

Most of it went over my head, but there's so much knowledge and expertise on display here that it makes me proud that this person I've never met is out there proving that software development isn't entirely full of clowns.

Seb is incredibly passionate about games and graphics programming. You can find old posts of his on various forums, talking about tricks for programming the PS2, PS3, Xbox 360, etc etc. He regularly posts demos he's working on, progress clips of various engines, etc, on twitter, after staying in the same area for 3 decades.

I wish I still had this level of motivation :)

Re: No Graphics API

#92

Post by [deleted] »

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…

[deleted]

Re: No Graphics API

#93

Post by Pannoniae »

ginko wrote: post #29

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

A preprocessor step mostly solves this one. No one said that the shader source has to go into the GPU API 1:1.

Basically do what most engines do - have preprocessor constants and use different paths based on what attributes you need.

I also don't see how separated pipeline stages are against this - you already have this functionality in existing APIs where you can swap different stages individually. Some changes might need a fixup from the driver side, but nothing which can't be added in this proposed API's `gpuSetPipeline` implementation...

Re: No Graphics API

#94

Post by Scaevolus »

cyber_kinetist wrote: post #89
henning wrote: post #3

This looks very similar to the SDL3 GPU API and other RHI libraries that have been created at first glance.

If you look at the details you can clearly see SDL3_GPU is wildly different from this proposal, such as: - It's not exposing raw GPU addresses, SDL3_GPU has buffer objects instead. Also you're much more limited with how you use buffers in SDL3 (ex. no coherent buffers, you're forced to use a transfer buffer if you want to do a CPU -> GPU upload) - in SDL3_GPU synchronization is done automatically, without the user sp…

SDL3 is kind of the intersection of features found in DX12/Vulkan 1.0/Metal: if it's not easily supported in all of them, it's not in SDL3-- hence the lack of bindless support. That means you can run on nearly every device in the last 10-15 years.

This "no api" proposal requires hardware from the last 5-10 years :)

Re: No Graphics API

#95

Post by ablob »

jsheard wrote: post #61
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.

Eh, I think the jury is still out on whether unifying desktop and mobile graphics APIs is really worth it. In practice Vulkan written to take full advantage of desktop GPUs is wildly incompatible with most mobile GPUs, so there's fragmentation between them regardless.

I feel like it's a win by default. I do like to write my own programs every now and then and recently there's been more and more graphics sprinkled into them. Being able to reuse those components and just render onto a target without changing anything else seems to be very useful here. This kind of seamless interoperability between platforms is very desirable in my book. I can't think of a better approach to achieve this than the graphics API itself.

Also there is no inherent thing that blocks extensions by default. I feel like a reasonable core that can optionally do more things similar to CPU extensions (i.e. vector extensions) could be the way to go here.

Re: No Graphics API

#96

Post by m-schuetz »

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 boilerplate, just provide the bindings as launch args to the draw call like draw(numTriangles, args), with args being something like draw(numTriangles, {uniformBuffer, positions, uvs, samplers}), depending on whatever the shaders expect.

Re: No Graphics API

#97

Post by cyber_kinetist »

Scaevolus wrote: post #94
cyber_kinetist wrote: post #89

Earlier quoted context omitted.

If you look at the details you can clearly see SDL3_GPU is wildly different from this proposal, such as: - It's not exposing raw GPU addresses, SDL3_GPU has buffer objects instead. Also you're much more limited with how you use buffers in SDL3 (ex. no coherent buffers, you're forced to use a transfer buffer if you want to do a CPU -> GPU upload) - in SDL3_GPU synchronization is done automatically, without the user sp…

SDL3 is kind of the intersection of features found in DX12/Vulkan 1.0/Metal: if it's not easily supported in all of them, it's not in SDL3-- hence the lack of bindless support. That means you can run on nearly every device in the last 10-15 years. This "no api" proposal requires hardware from the last 5-10 years :)

Yup you've actually pointed out the most important difference: SDL3 is designed to be compatible with the APIs and devices of the past (2010s), whereas this proposal is designed to be compatible with the newer 2020s batch of consumer devices.

Re: No Graphics API

#98

Post by 01HNNWZ0MV43FF »

jsheard wrote: post #61
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.

Eh, I think the jury is still out on whether unifying desktop and mobile graphics APIs is really worth it. In practice Vulkan written to take full advantage of desktop GPUs is wildly incompatible with most mobile GPUs, so there's fragmentation between them regardless.

If the APIs aren't unified, the engines will be, since VR games will want to work on both standalone headsets and streaming headsets

Re: No Graphics API

#99

Post by mikestorrent »

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

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

Re: No Graphics API

#100

Post by erwincoumans »

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…

Yes, an amazing and detailed post, enjoyed all of it. In AI, it is common to use jit compilers (pytorch, jax, warp, triton, taichi, ...) that compile to cuda (or rocm, cpu, tpu, ...). You could write renderers like that, rasterizers or raytracers.

For example: https://github.com/StafaH/mujoco_warp/blob/render_context/mu...

(A new simple raytracer that compiles to cuda, used for robotics reinforcement learning, renders at up to 1 million fps at low resolution, 64x64, with textures, shadows)

Post reply on HN