SDL
SDL copied to clipboard
libsdl-org
GPU: Android spec unreasonable
SDL_GPU makes the Vulkan feature shaderClipDistance mandatory at startup (added in https://github.com/libsdl-org/SDL/pull/10964) but this feature has very limited support on Android. (only 65% of Android devices support it as catalogued by Vulkan Hardware Database.) It also is not used for anything in SDL_GPU itself, but seems to only be in place for the possibility that shaders might want to use it. https://github.com/libsdl-org/SDL/issues/10860 mentions not supporting "low spec" Android but as it stands, the Android port of my SDL_GPU application cannot even run on my Pixel 9 Pro, which is a new flagship device.
I can't ship SDL_GPU if it's requiring features that aren't even supported on a new flagship. Why were choices made to force this feature requirement when it does not even work with the devices it is supposed to target?
Why were choices made to force this feature requirement when it does not even work with the devices it is supposed to target?
We aren't targeting Android devices, to be honest with you - Android vendors have a lot of catching up to do before we can even start to support those types of devices reliably. We do have it working on Tegra hardware, but that's about all the SDL_GPU team is willing to look at for now.
For now the best way to look at it is that it's the SDL_GPU spec rather than any one particular OS spec; we target everything from desktop to Nintendo Switch, and even Haiku works from what I understand, Android is the odd one out for the time being.
The SDL_GPU team's perspective is that Android is an unreasonable spec. Every single other platform (desktop, mobile, console) supports a wide range of features that are spotty on Android. The WebGPU project ran into this same problem and decided to solve it with optional extensions. We've chosen a different approach: no extensions. We provide one feature set / min spec that covers the vast majority of devices across operating systems and graphics APIs.
Our min spec does exclude a lot of Android devices, but this is just indicative of the state of Android graphics development. It's miserable. Khronos and Google both fully acknowledge this situation, and have provided "Vulkan roadmaps" to indicate which features and extensions you can expect to be broadly supported in a given year. These specs are extremely low, and any attempts to move the specs forward are constantly fought against by the device manufacturers. Maybe in 10 years time the situation will have improved, but looking back 10 years it seems like the Android graphics situation hasn't improved much.
We're not opposed to widening our Android support, but we don't want to sacrifice the "one feature set, no extensions" principle. So if something works on one graphics API we support, it should work on all of them. shaderClipDistance (and depthClamp) work out of the box on D3D12 and Metal, so we match that with Vulkan. Maybe there are workarounds for specific issues that we could document, but as flibitijibibo said, we're not actively looking into Android so someone else would need to contribute that.
Makes sense, thank you for sharing the rationale behind these decisions. I would like to point out that the documentation does not say anything about this beyond that Vulkan supports "certain" Android devices. I ran gpuinfo-vulkan-query with SDL_GPU's required features, and it excludes every Mali GPU. The only supported hardware is the aforementioned Tegra, along with Adreno 6-series and newer, PowerVR Rogue, Samsung Xclipse, and a few one-off chips. Since you're choosing to have such restricted support for Android, I can only suggest that this is reflected in documentation so that people do not get the impression the platform has the same level of support as others. Thank you for your time!
That sounds fair to me - @thatcosmonaut, @TheSpydog, anything to add?
After thinking on this a bit, I have an idea that could theoretically improve Android device compatibility in addition to making it easier for people to enable any special shader features their app needs.
@zachrammell Since you're more familiar with the Android ecosystem, if we eliminated the requirement for shaderClipDistance (with ~65% support), what major devices would still be excluded by requiring depthClamp (with ~79% support)?
After thinking on this a bit, I have an idea that could theoretically improve Android device compatibility in addition to making it easier for people to enable any special shader features their app needs.
@zachrammell Since you're more familiar with the Android ecosystem, if we eliminated the requirement for
shaderClipDistance(with ~65% support), what major devices would still be excluded by requiringdepthClamp(with ~79% support)?
I would be very interested if you improve Android support for SDL GPU.
I think the best guidance to follow would be https://developer.android.com/ndk/guides/graphics/android-baseline-profile, also see https://www.khronos.org/developers/linkto/android-baseline-profile-overview
From ABP 2021:
"features": {
"VkPhysicalDeviceFeatures": {
"depthBiasClamp": true,
"fragmentStoresAndAtomics": true,
"fullDrawIndexUint32": true,
"imageCubeArray": true,
"independentBlend": true,
"robustBufferAccess": true,
"sampleRateShading": true,
"shaderSampledImageArrayDynamicIndexing": true,
"shaderStorageImageArrayDynamicIndexing": true,
"shaderUniformBufferArrayDynamicIndexing": true,
"textureCompressionASTC_LDR": true,
"textureCompressionETC2": true
}
},
So depthClamp, shaderClipDistance and drawIndirectFirstInstance. drawIndirectFirstInstance is in VP_ANDROID_15_minimums.json but that's way too few devices.
@flibitijibibo, we'd like to ship 3.4 soon, what needs to be done on this bug?
I think we've covered this with the addition of various Vulkan device properties - @TheSpydog, have we missed anything?
As far as I'm aware, the Vulkan properties we expose should be sufficient. Developers can opt out of whichever features they don't need for their app in order to target a broader range of Android devices.