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

121–130 of 186 posts

Re: No Graphics API

#121

Post by m-schuetz »

flohofwoe wrote: post #120
m-schuetz wrote: post #117

Earlier quoted context omitted.

No longer an issue with dynamic rendering and shader objects. And never was an issue with OpenGL. Static pipelines are an artificial problem that Vulkan imposed for no good reason, and which they reverted in recent years.

Going entirely back to the granular GL-style state soup would have significant 'usability problems'. It's too easy to accidentially leak incorrect state from a previous draw call. IMHO a small number of immutable state objects is the best middle ground (similar to D3D11 or Metal, but reshuffled like described in Seb's post).

Not using static pipelines does not imply having to use a global state machine like OpenGL. You could also make an API that uses a struct for rasterizer configs and pass it as an argument to a multi draw call. I would have actually preferred that over all the individual setters in Vulkan's dynamic rendering approach.

Re: No Graphics API

#122

Post by bullen »

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, only soft internal protocols can now evolve, I write mine inside TCP/HTTP.

Re: No Graphics API

#123

Post by hrydgard »

modeless wrote: post #90
yuriks wrote: post #85

Earlier quoted context omitted.

I thought that the implication was that the shader compiler produces a second shader from the same source that went through a dead code elimination pass which maintains only the code necessary to calculate the position, ignoring other attributes.

Sure, but that only goes so far, especially when users aren't writing their shaders with knowledge that this transform is going to be applied or any tools to verify that it's able to eliminate anything.

Well, it is what is done on several tiler architectures, and it generally works just fine. Normally your computations of the position aren't really intertwined with the computation of the other outputs, so dead code elimination does a good job.

Re: No Graphics API

#124

Post by tonis2 »

wbobeirne wrote: post #39
flohofwoe wrote: post #11

Earlier quoted context omitted.

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?

Getting rid of cruft and simplifying the GPU access, makes it easier to develope software that uses GPU's, like AI's, games ..etc.

Have you taken a look at the codebase of some game-engines, its complete cluster fk, cause some simple tasks just take 800 lines of code, and in the end the drivers don't even use the complexity graphics API's force upon you.

Improved this is not an accomplishment ?

Re: No Graphics API

#125

Post by exDM69 »

vblanco wrote: post #2

This is a fantastic article that demonstrates how many parts of vulkan and DX12 are no longer needed. I hope the IHVs have a look at it because current DX12 seems semi abandoned, with it not supporting buffer pointers even when every gpu made on the last 10 (or more!) years can do pointers just fine, and while Vulkan doesnt do a 2.0 release that cleans things, so it carries a lot of baggage, and specially, tons of dr…

> tons of drivers that dont implement the extensions that really improve things.

This isn't really the case, at least on desktop side.

All three desktop GPU vendors support Vulkan 1.4 (or most of the features via extensions) on all major platforms even on really old hardware (e.g. Intel Skylake is 10+ years old and has all the latest Vulkan features). Even Apple + MoltenVK is pretty good.

Even mobile GPU vendors have pretty good support in their latest drivers.

The biggest issue is that Android consumer devices don't get GPU driver updates so they're not available to the general public.

Re: No Graphics API

#126

Post by theandrewbailey »

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 for GPU rendering to make the most of them.

Uh oh https://www.amazon.com/ASUS-Swift-Gaming-Monitor-PG27AQDP/dp...

Re: No Graphics API

#127

Post by webdevver »

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 memory was unthinkiable in the 70s. but for us, its unthinkable to have real-time frame inferencing. I cant help but draw the parallels between our current-day "clever algorithmic ways" of drawing pixels to the screen.

I definitely agree with the take that in the grand scheme of things, all this pixel rasterizing business will be a transient moment that will be washed away with a much simpler petaflop/exaflop local TPU that runs at 60W under load, and it simply 'dreams' frames and textures for you.

Re: No Graphics API

#128

Post by qiine »

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

Re: No Graphics API

#129

Post by speed_spread »

Antibabelic wrote: post #109
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.…

"Offtop" is not a word. It's not in any English dictionary I could find and doesn't appear in any published literature. Matthew 7:3 "And why beholdest thou the mote that is in thy brother's eye, but considerest not the beam that is in thine own eye?"

Language evolves in mysterious ways. FWIW I find offtop to have high cromulency.

Re: No Graphics API

#130

Post by pjmlp »

exDM69 wrote: post #125
vblanco wrote: post #2

This is a fantastic article that demonstrates how many parts of vulkan and DX12 are no longer needed. I hope the IHVs have a look at it because current DX12 seems semi abandoned, with it not supporting buffer pointers even when every gpu made on the last 10 (or more!) years can do pointers just fine, and while Vulkan doesnt do a 2.0 release that cleans things, so it carries a lot of baggage, and specially, tons of dr…

> tons of drivers that dont implement the extensions that really improve things. This isn't really the case, at least on desktop side. All three desktop GPU vendors support Vulkan 1.4 (or most of the features via extensions) on all major platforms even on really old hardware (e.g. Intel Skylake is 10+ years old and has all the latest Vulkan features). Even Apple + MoltenVK is pretty good. Even mobile GPU vendors have…

Neither do laptops, where not using the driver from the OEM with whatver custom code they added can lead to interesting experiences, like power configuration going bad, not able to handle the mixed GPU setups, and so on.
Post reply on HN