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

31–40 of 186 posts

Re: No Graphics API

#31

Post by jsheard »

mrec wrote: post #28
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.

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 inflexible hardware units.

Meanwhile GPU raytracing was a purely software affair until quite recently when fixed-function raytracing hardware arrived. It's fast but also opaque and inflexible, only exposed through high-level driver interfaces which hide most of the details, so you have to let Jensen take the wheel. There's nothing stopping someone from going back to software RT of course but the performance of hardware RT is hard to pass up for now, so that's mostly the way things are going even if it does have annoying limitations.

Re: No Graphics API

#32

Post by modeless »

yieldcrv wrote: post #8

what level of performance improvements would this represent?

It would likely reduce or eliminate the "compiling shaders" step many games now have on first run after an update, and the stutters many games have as new objects or effects come on screen for the first time.

Re: No Graphics API

#34

Post by djmips »

mrec wrote: post #28
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.

Why do you say 'albeit'? I think it's established that 'software rendering' can mean running on the GPU. That's what Octane is doing with CUDA in the comment you are replying to. But good callout on Nanite.

Re: No Graphics API

#35

Post by gmueckl »

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.

Re: No Graphics API

#36

Post by djmips »

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

Re: No Graphics API

#37

Post by djmips »

pjmlp wrote: post #20
ksec wrote: post #7

I wonder why M$ stopped putting out new Direct X? Direct X Ultimate or 12.1 or 12.2 is largely the same as Direct X 12. Or has the use of Middleware like Unreal Engine largely made them irrelevant? Or should EPIC put out a new Graphics API proposal?

That has always been the case, it is mostly FOSS circles that argue about APIs. Game developers create a RHI (rendering hardware interface) like discussed on the article, and go on with game development. Because the greatest innovation thus far has been ray tracing and mesh shaders, and still they are largely ignored, so why keep on pushing forward?

I disagree that ray tracing and mesh shaders are largely ignored - at least within AAA game engines they are leaned on quite a lot. Particularly ray tracing.

Re: No Graphics API

#38

Post by djmips »

ksec wrote: post #7

I wonder why M$ stopped putting out new Direct X? Direct X Ultimate or 12.1 or 12.2 is largely the same as Direct X 12. Or has the use of Middleware like Unreal Engine largely made them irrelevant? Or should EPIC put out a new Graphics API proposal?

The frontier of graphics APIs might be the consoles and they don't get a bump until the hardware gets a bump and the console hardware is a little bit behind.

Re: No Graphics API

#39

Post by wbobeirne »

flohofwoe wrote: post #11
yieldcrv wrote: post #8

what level of performance improvements would this represent?

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?
Post reply on HN