GPU Proposal: Lock in minimum requirements

[thatcosmonaut]

A lot of @TheSpydog and I's time this past month has been spent trying to figure out the scope limit for the feature set of SDL GPU. One problem has consistently shown itself over and over again: Android.

Android Vulkan feature sets are notoriously spotty. Features that are universally supported on every other platform have low support on Android, forcing us to make difficult restrictive decisions or turn the API into a mess of client queries. There doesn't seem to be much rhyme or reason to any of the feature omissions. It's worth noting that Nintendo Switch is basically Android hardware, but the feature set is robust, strongly implying that this is a vendor issue.

At this point it's difficult for me to argue that it would be a good idea to complicate the feature set of SDL GPU, which will almost certainly be used primarily to ship on desktop and console platforms, just to make concessions to Android. At least iOS as a mobile platform uses Metal and guarantees a broadly similar feature set to desktop MacOS.

We haven't even gotten into the litany of broken nonconformant Vulkan drivers on various Android hardware. What's our answer to that? Clients will just see the issues as our problem. Will we have to turn the Vulkan backend into a mess of driver-specific hacks for Android?

My proposal is simple: Android should not be supported by SDL GPU. Graphics on Android is a mess and I don't think anyone on this project wants to turn into a full-time Android support engineer.

Pinging @slouken and @icculus for comment on this.

[icculus]

This is fine with me. I'm not against changing this later if hardware/drivers improve, and we can even decide that without lifting a finger once the WebGPU backend is solid...we'd just need to see what Chrome does on various phones at that point.

[slouken]

Do what's right for the API on desktop, consoles and Metal. Android hardware and drivers will catch up, we're just starting out here. :)

[TheSpydog]

once the WebGPU backend is solid...we'd just need to see what Chrome does on various phones at that point.

It would definitely be nice to let the browser vendors handle the investigation of driver/OS-specific bugs!

Unfortunately, beyond that, WebGPU has the exact same limitations as supporting Android directly. The W3C working group didn’t actually solve any of the Android portability issues; rather, they punted them off to the user via extensions and optional features, just like Vulkan does.

So our WebGPU implementation will have many of the same problems as a homegrown Android Vulkan implementation — we’ll have to choose between (1) force-enabling a bunch of extensions and hoping for the best, (2) adding feature queries to the API for features that are guaranteed on every non-Android platform, or (3) removing SDL_GPU features to accommodate these limitations.

(In a perfect world, we could add Vulkan physical device features and extensions to an Android manifest so that users with unsupported devices simply wouldn’t be able to install the app in the first place, but afaik that’s not the world we live in…)

[slouken]

I would lean towards a combination of 2 and 3. Identify the feature set that makes the most sense that is supported across non-Android platforms, and then require those extensions on WebGPU and Android platforms.

[flibitijibibo]

That all makes sense to me - so what we'll do is take our current min spec and lock it in; Metal should work on A9 and newer and Vulkan will work on virtually every desktop driver from Q4 2018 and newer. Android will almost certainly hate this but they've got 10 years to claw their way to 6 years ago!

We can document this via a comment in the overview for #10830 and a Vulkan Profile.

[thatcosmonaut]

This all sounds good to me. I'm going to review the Vulkan implementation to see if there's anything we can simplify now that we're ruling out low spec Android.

[DyXel]

Dumb question: Is it possible in theory to write a layer that would abstract GL into Vulkan, akin to DXVK, i.e.: Would it be possible to create "VKGL" to support platforms that have OpenGL support only?

My main concern is supporting older devices that no longer get updates and things like that. They are perfectly fine, except that due to constraints out of end-users hand, they become e-waste. It's a sad situation.

[TheSpydog]

Identify the feature set that makes the most sense that is supported across non-Android platforms, and then require those extensions on WebGPU and Android platforms.

Requiring extensions is what I meant by my option 1. For WebGPU in the browser, that’s fine, the webpage could just display a “Your device is not supported” message instead of the canvas.

But for Android, what is the expected behavior if a device doesn’t support an extension we require? Is it normal for an app to display an error message and auto-close on startup if the device is lacking feature support, or would that be considered a Google Play cert failure?

If it’s the former, then we should probably communicate this explicitly in the Android readme so developers can set up their initialization accordingly.

[icculus]

But for Android, what is the expected behavior if a device doesn’t support an extension we require? Is it normal for an app to display an error message and auto-close on startup if the device is lacking feature support, or would that be considered a Google Play cert failure?

I don't think they have a rule about this.

But what Google Play does have is a way to specify what devices an app is compatible with, so users without compatible phones will be told they can't even install in the first place. For something that really doesn't work unless you have one of a handful of good phones, it's not unreasonable to block everything but those.

Do we know if there's any Android phone that would be usable? Like if you're willing to buy the 1000-dollar Android it works roughly as well as a 1000-dollar iPhone, even if the 30-dollar burner you bought at Walmart is never going to work, or is Vulkan just sort of bad across the board on Android right now?

(And/or is it a case where the 30-dollar burner is totally going to claim to support needed extensions but it doesn't actually work?)

I'm just asking, but for 3.2.0 (and the foreseeable future), we can just absolutely return -1 on Android (or only compile a theoretical "dummy" backend for that platform).

[slime73]

Is this what Google is trying to solve with https://developer.android.com/ndk/guides/graphics/android-baseline-profile ? Can SDL_GPU just document that support for one of those is required on Android?

[TheSpydog]

@icculus

Do we know if there's any Android phone that would be usable?

Looking at https://vulkan.gpuinfo.org/ it seems that a decent percentage (~45-70%) of Android devices claim to support the features and extensions we need. Although...

(And/or is it a case where the 30-dollar burner is totally going to claim to support needed extensions but it doesn't actually work?)

Yeah, this is very likely. App developers would need to trial-and-error through different devices to figure out which ones actually work as advertised. Some of the features are only missing on specific hardware vendors (particularly Mali...) so at least for those cases I guess it wouldn't be too difficult narrow down the allowed device list.

@slime73

Is this what Google is trying to solve with https://developer.android.com/ndk/guides/graphics/android-baseline-profile ? Can SDL_GPU just document that support for one of those is required on Android?

Sadly no, the baseline profiles don't include all the features we need. Even if they did, the Android device vendors are under no obligation to stick to the 2022 profile. They're just "encouraged" to. (There will also be no more baseline profiles going forward...)

[thatcosmonaut]

Dumb question: Is it possible in theory to write a layer that would abstract GL into Vulkan, akin to DXVK, i.e.: Would it be possible to create "VKGL" to support platforms that have OpenGL support only?

My main concern is supporting older devices that no longer get updates and things like that. They are perfectly fine, except that due to constraints out of end-users hand, they become e-waste. It's a sad situation.

Supporting GL on SDL GPU involves emulating command buffers, which would be a huge amount of work that I don't think any of us have time for.

GL is effectively a dead API so there's not much of a pathway for the future. Vulkan itself has been around for almost 10 years so it's not exactly bleeding edge. We're doing our best to support older devices but we need to put a reasonable cutoff somewhere.

[DyXel]

no worries, I am just trying to understand if it would be theoretically possible. I completely get the point that if vendors don't want to put the effort in, you guys can't work miracles. But it is sad that a gazillion of older devices must remain unsupported due to this mess.

[thatcosmonaut]

Yeah this situation is 100% on the vendors and Google being unwilling or unable to put controls on the ecosystem they created, we are downstream of that whole mess and have to do our best.

[captain0xff]

@icculus

Do we know if there's any Android phone that would be usable?

Looking at https://vulkan.gpuinfo.org/ it seems that a decent percentage (~45-70%) of Android devices claim to support the features and extensions we need. Although...

(And/or is it a case where the 30-dollar burner is totally going to claim to support needed extensions but it doesn't actually work?)

Yeah, this is very likely. App developers would need to trial-and-error through different devices to figure out which ones actually work as advertised. Some of the features are only missing on specific hardware vendors (particularly Mali...) so at least for those cases I guess it wouldn't be too difficult narrow down the allowed device list.

@slime73

Is this what Google is trying to solve with https://developer.android.com/ndk/guides/graphics/android-baseline-profile ? Can SDL_GPU just document that support for one of those is required on Android?

Sadly no, the baseline profiles don't include all the features we need. Even if they did, the Android device vendors are under no obligation to stick to the 2022 profile. They're just "encouraged" to. (There will also be no more baseline profiles going forward...)

According to https://developer.android.com/about/dashboards/index.html#Vulkan the baseline profile (2022) is supported in around 80% devices.

[thatcosmonaut]

Once again, the baseline profile does not actually indicate which Vulkan features are actually enabled, and some of those features are universally supported everywhere but Android, which makes our lives very difficult as a write-once-run-everywhere abstraction.

[icculus]

Okay, yeah, let's just punt on Android for now. They still have the 2D API and OpenGL ES until the world improves.

[slouken]

Okay, yeah, let's just punt on Android for now. They still have the 2D API and OpenGL ES until the world improves.

We shouldn't punt on Android. We should enable the GPU subsystem and fail if required extensions aren't present. If we have to whitelist/blacklist chipsets/Android versions we can do that too, but we should have a known good set of devices for GPU support out of the gate.

[thatcosmonaut]

Yeah I think it's fine for people to use this on Android as long as we make it very clear that we do not support hardware just because it runs Android.

[slouken]

Is there a certain Android version that mostly has the functionality we need across vendors?

[TheSpydog]

We could maybe target Android devices that support Vulkan 1.2 or higher? Technically supporting 1.2 doesn’t guarantee the features and extensions we need, but there’s a very strong correlation between higher version support and overall feature support. It seems that vendors who stay up to date with the Vulkan standards also tend to put more effort into their drivers.

Unfortunately I have no idea what percentage of devices support 1.2 since Google omitted it from their dashboard: https://developer.android.com/about/dashboards#Vulkan

[captain0xff]

This page has some information regarding that. Though this also omits 1.2. https://source.android.com/docs/core/graphics/implement-vulkan#versions