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

181–186 of 186 posts

Re: No Graphics API

#181

Post by m-schuetz »

kllrnohj wrote: post #179
flohofwoe wrote: post #167

Earlier quoted context omitted.

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

But they don't actually differ, see the "no graphics API" blog post we're all commenting on :) The primary difference between mobile & desktop is performance, not feature set (ignoring for a minute the problem of outdated drivers). And beyond that if you look at historical trends, mobile is and always has been just "desktop from 5-7 years ago". An API split that makes sense now will stop making sense rather quickly.

Different features/architecture is precisely the issue with mobile, be it due to hardware constraints or due to lack in deiver support. Render passes were only bolted into Vulkan because of mobile tiler GPUs, they never made any sense for desktop GPUs and only made Vulkan worse for desktop graphics development.

And this is the reason why mobile and desktop should be separate graphics APIs. Mobile is holding desktop back not just feature wise, it also fucks up the API.

Re: No Graphics API

#182

Post by canyp »

SunlitCat wrote: post #178
canyp wrote: post #87

Earlier quoted context omitted.

> but I even remember some IHV saying that this level of control isn’t always a good thing. Because that control is only as good as you can master it, and not all game developers do well on that front. Just check out enhanced barriers in DX12 and all of the rules around them as an example. You almost need to train as a lawyer to digest that clusterfuck. > The hardware (and its driver) could then decide what’s optimal…

The problem with DX12/Vulkan isn’t just that “low-level control is hard”, it’s that a lot of performance-critical decisions are now exposed at a level where they’re extremely GPU- and generation-specific. The same synchronization strategy, command ordering, or memory usage can work great on one GPU and badly on another. A GPU ISA wouldn’t fix that, it would push even more of those decisions onto the developer. An ISA…

But the driver can't decide how to execute efficiently more than the application does, that's how we got the modern APIs. The declarative API would necessarily have to tackle very specific use cases, which again is what the older APIs did.

So I guess we're stuck with what exists today for a while.

Re: No Graphics API

#183

Post by deliciousturkey »

kllrnohj wrote: post #132
deliciousturkey wrote: post #116

Earlier quoted context omitted.

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…

The context was

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.

In this context, both old Switch and Switch 2 have full desktop-class GPUs. They don't need to care about the API problems that mobile vendors imposed to Vulkan.

Re: No Graphics API

#184

Post by torginus »

jsheard wrote: post #21
m-schuetz wrote: post #19

Earlier quoted context omitted.

Valve seems to be substantially responsible for the mess that is Vulkan. They were one of its pioneers from what I heard when chatting with Vulkan people.

There's plenty of blame to go around, but if any one faction is responsible for the Vulkan mess it's the mobile GPU vendors and Khronos' willingness to compromise for their sake at every turn. Huge amounts of API surface was dedicated to accommodating limitations that only existed on mobile architectures, and earlier versions of Vulkan insisted on doing things the mobile way even if you knew your software was only ev…

Which is very weird, considering mobile GPUs by their very nature use unified memory, so supporting things like bindless and GPU pointers (which in this case are just pointers) would be more straightforward than on PC, where basically you have 2 computers with separate memory spaces connected via PCI Express

Re: No Graphics API

#185

Post by MindSpunk »

torginus wrote: post #184
jsheard wrote: post #21

Earlier quoted context omitted.

There's plenty of blame to go around, but if any one faction is responsible for the Vulkan mess it's the mobile GPU vendors and Khronos' willingness to compromise for their sake at every turn. Huge amounts of API surface was dedicated to accommodating limitations that only existed on mobile architectures, and earlier versions of Vulkan insisted on doing things the mobile way even if you knew your software was only ev…

Which is very weird, considering mobile GPUs by their very nature use unified memory, so supporting things like bindless and GPU pointers (which in this case are just pointers) would be more straightforward than on PC, where basically you have 2 computers with separate memory spaces connected via PCI Express

Bindless has nothing to do with UMA and everything to do with the fundamentals of how your GPU accesses memory. Older GPUs had limited register spaces where they could store texture and buffer references, the hardware had no instructions to read textures or buffers outside of the references in those small set of hardware registers. They just weren't able to issue a request to the texture unit to read any old texture, it had to be in that set. The GPU itself wasn't able to update those registers, only the CPU could.

UMA or not doesn't matter, desktop GPUs have MMUs and are perfectly capable of reading the CPUs memory in a unified address space (even back then).

Re: No Graphics API

#186

Post by MindSpunk »

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

Earlier quoted context omitted.

> Also, WebGL did just fine without pipelines, despite being mapped to Vulkan and DirectX code under the hood. ...at the cost of creating PSOs at random times which is an expensive operation :/

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.

That's not at all what dynamic rendering is for. Dynamic rendering avoids creating render pass objects, and does nothing to solve problems with PSOs. We should be glad for the demise of render pass objects, they were truly a failed experiment and weren't even particularly effective at their original goal.

Trying to say pipelines weren't a problem with OpenGL is monumental levels of revisionism. Vulkan (and D3D12, and Metal) didn't invent them for no reason. OpenGL and DirectX drivers spent a substantial amount of effort to hide PSO compilation stutter, because they still had to compile shader bytecode to ISA all the same. They were often not successful and developers had very limited tools to work around the stutter problems.

Often older games would issue dummy draw calls to an off screen render target to force the driver to compile the shader in a loading screen instead of in the middle of your frame. The problem was always hard, you could just ignore it in the older APIs. Pipelines exist to make this explicit.

The mistake Vulkan made was putting too much state in the pipeline, as much of that state is dynamic in modern hardware now. As long as we need to compile shader bytecode to ISA we need some kind of state object to represent the compiled code and APIs to control when that is compiled.

Post reply on HN