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

161–170 of 186 posts

Re: No Graphics API

#161

Post by cubefox »

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…

It is more likely that machine learning models will be used by the game artists for asset generation, but not for rendering those assets at the client side, which would be extremely expensive.

But another upcoming use case of ML on the client side is neural texture compression, which somehow needs not just less storage but also less RAM. Though it comes at a computational (frame time) cost on the client side, though not as bad as generative AI.

Neural mesh compression could be another potential thing we get in the future. (All lossy compression seems to go in the ML direction: currently there is a lot of work going on with next generation neural audio and video codecs. E.g. https://arxiv.org/abs/2502.20762)

Re: No Graphics API

#162

Post by eek2121 »

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 definitely disagree here. What matters for mobile is power consumption. Capabilities can be pretty easily implemented...if you disagree, ask Apple. They have seemingly nailed it (with a few unrelated limitations).

Mobile vendors insisting on using closed, proprietary drivers that they refuse to constantly update/stay on top of is the actual issue. If you have a GPU capable of cutting edge graphics, you have to have a top notch driver stack. Nobody gets this right except AMD and NVIDIA (and both have their flaws). Apple doesn't even come close, and they are ahead of everyone else except AMD/NVIDIA. AMD seems to do it the best, NVIDIA, a distant second, Apple 3rd, and everyone else 10th.

Re: No Graphics API

#163

Post by m-schuetz »

Archit3ch wrote: post #158
m-schuetz wrote: post #134

Earlier quoted context omitted.

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.

> Problem is that NVIDIA literally makes the only sane graphics/compute APIs. Hot take, Metal is more sane than CUDA.

I'm having a hard time taking an API seriously that uses atomic types rather than atomic functions. But at least it seems to be better than Vulkan/OpenGL/DirectX.

Re: No Graphics API

#164

Post by pjmlp »

torginus wrote: post #152
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…

I really want to make a game using a software rasterizer sometime - just to prove its possible. Back in the good ol' days, I had to get by on my dad's PC, which had no graphics acceleration, but a farily substatial Pentium 3 processor. Games like the original Half-Life, Unreal Tournament 2004, etc. ran surprisingly well and at decent resolutions. With the power of modern hardware, I guess you could do a decent FPS in…

You could start by staying on the CPU side, and make use of AVX, Larrabee style.

Which is easier to debug.

Going with Mesh shaders, or GPU compute would be the next step.

Re: No Graphics API

#165

Post by HelloNurse »

m-schuetz wrote: post #154
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.

On the contrary, I would say this is the main thing Vulkan got wrong and the main reason whe the API is so bad. Desktop and mobile are way too different for a uniform rendering API. They should be two different flavours with a common denominator. OpenGL and OpenGL ES were much better in that regard.

It is unreasonable to expect to run the same graphics code on desktop GPUs and mobile ones: mobile applications have to render something less expensive that doesn't exceed the limited capabilities of a low-power device with slow memory.

The different, separate engine variants for mobile and desktop users, on the other hand, can be based on the same graphics API; they'll just use different features from it in addition to having different algorithms and architecture.

Re: No Graphics API

#166

Post by HelloNurse »

jsheard wrote: post #31
mrec wrote: post #28

Earlier quoted context omitted.

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.

Things are kind of heading in two opposite directions at the moment. Early GPU rasterization was all done in fixed-function hardware, but then we got programmable shading, and then we started using compute shaders to feed the HW rasterizer, and then we started replacing the HW rasterizer itself with more compute (as in Nanite). The flexibility of doing whatever you want in software has gradually displaced the inflexi…

And hardware raytracing is on the same trajectory as hardware rasterization: devs finding ways to repurpose it, leading to pressure for more general APIs, which enable further repurposing, until hardware raytracing evolves into a flexible hardware accelerated facility for indexing, reordering, etc.

Re: No Graphics API

#167

Post by flohofwoe »

HelloNurse wrote: post #165
m-schuetz wrote: post #154

Earlier quoted context omitted.

On the contrary, I would say this is the main thing Vulkan got wrong and the main reason whe the API is so bad. Desktop and mobile are way too different for a uniform rendering API. They should be two different flavours with a common denominator. OpenGL and OpenGL ES were much better in that regard.

It is unreasonable to expect to run the same graphics code on desktop GPUs and mobile ones: mobile applications have to render something less expensive that doesn't exceed the limited capabilities of a low-power device with slow memory. The different, separate engine variants for mobile and desktop users, on the other hand, can be based on the same graphics API; they'll just use different features from it in addition…

> they'll just use different features from it in addition to having different algorithms and architecture.

...so you'll have different code paths for desktop and mobile anyway. The same can be achieved with a Vulkan vs VulkanES split which would overlap for maybe 50..70% of the core API, but significantly differ in the rest (like resource binding).

Re: No Graphics API

#168

Post by flohofwoe »

awolven wrote: post #79

Is this going to materialize into a "thing"?

I see it more like a rallying call to the GPU vendors, Microsoft, Khronos and Apple what the next major versions of D3D, Vulkan and Metal should look like.

Re: No Graphics API

#169

Post by aleph_minus_one »

eek2121 wrote: post #162
jsheard wrote: post #61

Earlier quoted context omitted.

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 definitely disagree here. What matters for mobile is power consumption. Capabilities can be pretty easily implemented...if you disagree, ask Apple. They have seemingly nailed it (with a few unrelated limitations). Mobile vendors insisting on using closed, proprietary drivers that they refuse to constantly update/stay on top of is the actual issue. If you have a GPU capable of cutting edge graphics, you have to have…

> If you have a GPU capable of cutting edge graphics, you have to have a top notch driver stack. Nobody gets this right except AMD and NVIDIA (and both have their flaws). Apple doesn't even come close, and they are ahead of everyone else except AMD/NVIDIA. AMD seems to do it the best, NVIDIA, a distant second, Apple 3rd, and everyone else 10th.

What about Intel?

Re: No Graphics API

#170

Post by aleph_minus_one »

eek2121 wrote: post #159
torginus wrote: post #151

Earlier quoted context omitted.

It's weird how the 'next-gen' APIs will turn out to be failures in many ways imo. I think still as sizeable amount of graphics devs still stuck to the old way of doing things. I know a couple graphics wizards (who work on major AAA titles) who never liked Vulkan/DX12, and many engines haven't really been rebuilt to accomodate the 'new' way of doing graphics. Ironically a lot of the time, these new APIs end up being s…

I think the big issue is that there is no 'next-gen API'. Microsoft has largely abandoned DirectX, Vulkan is restrictive as anything, Metal isn't changing much beyond matching DX/Vk, and NVIDIA/AMD/Apple/Qualcomm aren't interested in (re)-inventing the wheel. There are some interesting GPU improvements coming down the pipeline, like a possible OoO part from AMD (if certain credible leaks are valid), however, crickets…

> Microsoft has largely abandoned DirectX

What does Microsoft then intend to use to replace the functionality that DirectX provides?

Post reply on HN