[pjmlp]

At least they are making an effort to correct the extension spaghetti, already worse than OpenGL.

Addiitionally most of these fixes aren't coming into Android, now getting WebGPU for Java/Kotlin[0] after so many refused to move away from OpenGL ES, and naturally any card not lucky to get new driver releases.

Still, better now than never.

[0] - https://developer.android.com/jetpack/androidx/releases/webg...

[viktorcode]

As someone from game development, not supporting Vulkan on Android and sticking with OpenGL ES instead is a safer bet. There is always some device(s) that bug out on Vulkan badly. Nobody wants to sit and find workarounds for that obscure vendor.

[tadfisher]

Bizarre take. Notice how that WebGPU is an AndroidX library? That means WebGPU API support is built into apps via that library and runs on top of the system's Vulkan or OpenGL ES API.

Do you work for Google or an Android OEM? If not, you have no basis to make the claim that Android will cease updating Vulkan API support.

[pjmlp]

I did not do such claim.

WebGPU on Android runs on top of Vulkan.

If you knew about 3D programming on Android, you would know that there are ongoing efforts to have only Vulkan, with OpenGL ES on top.

However Java and Kotlin devs refuse to bother with the NDK for Vulkan, and keep reaching for OpenGL ES instead.

Please refer to Google talks on Vulkanised conferences.

[flohofwoe]

> ...efforts to have only Vulkan, with OpenGL ES on top...

Ok this made me laugh given that Vulkan support on Android is so bad that WebGPU needs a fallback mode to GLES ;)

https://github.com/gpuweb/gpuweb/issues/4266

[pjmlp]

Agreed, which is Google's motivation for doing that.

The argument being that if Android only does Vulkan, that OEMs will be forced to care about their drivers.

There are talks done by Google on this, either Vulkanised, Google IO, or GDC, can't remember now the exact one.

[torginus]

Is it possible to support OpenGL on top of Vulkan well? It has been pointed out that Vulkan requires you to completely freeze and compile a graphics pipeline before using it, while OpenGL's state machine is more flexible, and the underlying hardware is somewhat more amenable to these state transitions at runtime, than the Vulkan API would suggest.

Don't these compatibility layers run into issues with constant pipeline recompilation related performance issues, when emulating OpenGL?

[pjmlp]

It is no different from running DirectX on Vulkan, DirectX or Vulkan on Metal.

It works, kind of.

[Hendrikto]

> Vulkan requires you to completely freeze and compile a graphics pipeline before using it

It used to be like that but it is no longer true.

[mirsadm]

Vulkan is awful to work with and the drivers are buggy. Google's own phones are the worst for it. I have an app with a compute only vulkan pipeline and on the Google Pixel 10 the whole screen becomes corrupted with some fairly basic shaders.