Unigine 2.16 Released With Experimental Vulkan Support

[qarium]

The situation got so bad, they had to introduce Profiles, in version 1.3.

why not make a market research what real games and real apps and real DEs use and then make these extensions a force in Vulkan 2.0

its very simple to fix in my point of view

[smitty3268]

why not make a market research what real games and real apps and real DEs use and then make these extensions a force in Vulkan 2.0

its very simple to fix in my point of view

Because the heaviest users of Vulkan are Android mobile devices, and they didn't want to actually create a separate API for each.

Which is exactly why they split a mobile profile out from the desktop one.

[qarium]

Because the heaviest users of Vulkan are Android mobile devices, and they didn't want to actually create a separate API for each.
Which is exactly why they split a mobile profile out from the desktop one.

over time the mobile devices pick up the same features ...

technically this is easy to fix..

[coder]

Because the heaviest users of Vulkan are Android mobile devices, and they didn't want to actually create a separate API for each.

Which is exactly why they split a mobile profile out from the desktop one.

Agreed. Profiles are a better fix for this problem. They provide some degree of standardization, while still allowing the flexibility that the extension mechanism was intended to provide.

[marlock]

disclaimer: I am not an expert, this is all based on superficial impressions from light reading about the subject over the years. If I'm wrong, I'd love to learn more.

AFAIK Vulkan 1.1, 1.2 and 1.3 have basically happened by picking up vendorhspecific extensions, turning them into vendor-agnostic extensions, extensively testing them out in the field where made available then selecting from those what was worth becoming part of the main specification.

Sure it means there are a lot of extensions... but what exactly is wrong with that process? Should they add new functions directly into the main specification while still not having run those through the proving grounds? Isn't that a recipe for disaster (bloating the spec with useless/ill-conceived/obsolete functions and ultimately needing to drop vulkan for yet another API ground-up rewrite)?

If an app wants to go off the main specification an use extensions for a specific graphics operation/effect, can't it query the driver for its presence at runtime and decide if it can be used, if it should use a fallback path, or even just drop the graphics effects that are dependant on it?

IIRC OpenGL had issues with drivers advertising a certain version of the core API as supported despite a few mandatory features not actually being present or, more common, being broken. Vulkan already took care of that much better with an exteeeeensive conformance testing suite (for core specifications and for each extension) and IIRC each extension is required to have a set of conformance tests to even be considered for inclusion in the specification.

I'm not sure why a mobile profile is desired. In may layman eyes mobile devices don't really need/have anything that a desktop wouldn't also need/have, but maybe I'm wrong and that's exactly why this would make sense? Or it's because there are other devices to be taken into account along desktops and mobile, with even smaller needs/possibilities than mobile (eg: embeded)?

A desktop profile going beyond the minimal spec OTOH is easy to understand... the minimal spec must be implemented everywhere and the minimal desired set for destops is most likely going to be more extensive than what's necessary for mobile. Adding those extras to the base spec raises the bar for driver conformance on mobile devices needlessly, but devs for desktop apps would be happy to rest assured at least on those they can count on some extra stuff.

[coder]

disclaimer: I am not an expert, this is all based on superficial impressions from light reading about the subject over the years. If I'm wrong, I'd love to learn more.

You're asking this in the wrong place. Try re-posting it in the thread on the main Vulkan 1.3 release, for the greatest visibility among our resident Vulkan experts.

https://www.phoronix.com/review/vulkan-13-2022

AFAIK Vulkan 1.1, 1.2 and 1.3 have basically happened by picking up vendor-specific extensions, turning them into vendor-agnostic extensions, extensively testing them out in the field where made available then selecting from those what was worth becoming part of the main specification.

It's a fair question how much of the major spec revisions are entirely new features vs. promoted extensions, and one I can't answer.

Even so, I think the core specification is basically a lowest-common-denominator. So, the vast majority of extensions won't get promoted to become mandatory, because there will always be tiny, embedded and other niche devices that won't be able to support them. I presume there's also an eye towards keeping the core specification simple enough that new market entrants can plausibly developer their own drivers in a commercially-relevant timeframe, but maybe not.

I'm not sure why a mobile profile is desired. In may layman eyes mobile devices don't really need/have anything that a desktop wouldn't also need/have, but maybe I'm wrong and that's exactly why this would make sense?

Phone GPUs are more constrained by power limits & silicon die area than desktop GPUs. That has traditionally meant embracing some features (fp16?) not used much on desktops, while avoiding others. Conversely, perhaps there are extensions specific to small screens or power-sensitive devices that make little sense for desktop apps or platforms.

There's also another benefit to keeping platform support focused, which is that it lets vendors concentrate on speed and stability of a subset of features that apps are actually going to use, rather than having to play whack-a-mole with trying to implement & optimize any given oddball extension that only a handful of apps actually take advantage of. From an app developer's perspective, it not only saves them the trouble of a bunch of different feature queries, but it also tells the which features are likely to be fast & well-supported.