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.

▲

pjmlp 5 days ago | parent | next [-]

It is not unified, when the first thing an application has to do is to find out if their set of extension spaghetti is available on the device.

▲

m-schuetz 5 days ago | parent | prev | next [-]

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.

▲

HelloNurse 4 days ago | parent [-]

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.

▲

flohofwoe 4 days ago | parent [-]

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

▲

kllrnohj 4 days ago | parent [-]

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.

	▲	m-schuetz 3 days ago \| parent [-]
		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.

▲

eek2121 5 days ago | parent | prev | next [-]

Mobile is getting RT, fyi. Apple already has it (for a few generations, at least), I think Qualcomm does as well (I'm less familiar with their stuff, because they've been behind the game forever, however the last I've read, their latest stuff has it), and things are rapidly improving.

Vulkan is the actual barrier. On Windows, DirectX does an average job at supporting it. Microsoft doesn't really innovate these days, so NVIDIA largely drives the market, and sometimes AMD pitches in.

	▲	pjmlp 4 days ago \| parent [-]
		Where do you think many DirectX features came from? It has been mostly NVidia in collaboration with Microsoft, even HLSL traces back to Cg.

▲

flohofwoe 5 days ago | parent | prev | next [-]

> One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs.

In hindsight it really would have been better to have a separate VulkanES which is specialized for mobile GPUs.

	▲	pjmlp 5 days ago \| parent [-]
		Apparently in many Android devices it is still better to target OpenGL ES than Vulkan due to driver quality, outside Samsung and Google brands.

▲

jsheard 6 days ago | parent | prev [-]

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.

▲

kllrnohj 6 days ago | parent | next [-]

It's quite useful for things like skia or piet-gpu/vello or the general category of "things that use the GPU that aren't games" (image/video editors, effects pipelines, compute, etc etc etc)

▲

Groxx 6 days ago | parent | next [-]

would it also apply to stuff like the Switch, and relatively high-end "mobile" gaming in general? (I'm not sure what those chips actually look like tho)

there are also some arm laptops that just run Qualcomm chips, the same as some phones (tablets with a keyboard, basically, but a bit more "PC"-like due to running Windows).

AFAICT the fusion seems likely to be an accurate prediction.

▲

deliciousturkey 5 days ago | parent [-]

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.

▲

kllrnohj 5 days ago | parent [-]

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 launching with ~2 generations old GPUs.

	▲	deliciousturkey a day ago \| parent \| next [-]
		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.
	▲	pjmlp 5 days ago \| parent \| prev [-]
		Still beats the design of all Web 3D APIs, and has much better development tooling, let that sink in how behind they are.

▲

pjmlp 4 days ago | parent | prev | next [-]

Those already have their own abstraction API, and implementing a RHI isn't a big issue as FOSS circles make it to be.

▲

jsheard 6 days ago | parent | prev [-]

I suppose that's true, yeah. I was focusing too much on games specifically.

▲

ablob 5 days ago | parent | prev | next [-]

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.

▲

eek2121 5 days ago | parent | prev | next [-]

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.

▲

aleph_minus_one 4 days ago | parent [-]

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

▲

pjmlp 4 days ago | parent [-]

It is quite telling how good their iGPUs are at 3D that no one counts them in.

I remember there was time about 15 years ago, they were famous for reporting OpenGL capabilities as supported, when they were actually only available as software rendering, which voided any purpose to use such features in first place.

	▲	aleph_minus_one 4 days ago \| parent [-]
		I know that in the past (such as your mentioned 15 years ago) Intel GPUs did have driver issues. > It is quite telling how good their iGPUs are at 3D that no one counts them in. I'm not so certain about this: in > https://old.reddit.com/r/laptops/comments/1eqyau2/apuigpu_ti... APUs/iGPUs are compared, and here Intel's integrated GPUs seem to be very competitive with AMD's APUs. --- You of course have to compare dedicated graphics cards with each other, and similarly for integrated GPUs, so let's compare (Intel's) dedicated GPUs (Intel Arc), too: When I look at > https://www.tomshardware.com/reviews/gpu-hierarchy,4388.html the current Intel Arc generation (Intel-Arc-B, "Battlemage") seems to be competitive with entry-level GPUs of NVidia and AMD, i.e. you can get much more powerful GPUs from NVidia and AMD, but for a much higher price. I thus clearly would not call Intel's dedicated GPUs to be so bad "at 3D that no one counts them in".

▲

01HNNWZ0MV43FF 5 days ago | parent | prev [-]

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