Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I remembered it wrong too. Not even OpenGL ES 3.2 is mandatory, only if you claim that the device is capable of high-perfomance VR. Otherwise, OpenGL ES 2.0 is fine (but 3.1 lib and stub symbols must be available).

Source: Android 7.1 Compatibility Definition Document

Chapter 7.1.4:

Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodied and detailed in the Android SDK documentations. Device implementations SHOULD support OpenGL ES 3.0, 3.1, or 3.2 on devices capable of supporting it.

Chapter 3.3.1:

Note that device implementations MUST include libGLESv3.so and in turn, MUST export all the OpenGL ES 3.1 and Android Extension Pack function symbols as defined in the NDK release android-24. Although all the symbols must be present, only the corresponding functions for OpenGL ES versions and extensions actually supported by the device must be fully implemented.

Chapter 3.3.1.1:

Device implementations, if not including support of the Vulkan APIs:

- MUST report 0 VkPhysicalDevices through the vkEnumeratePhysicalDevices call.

- MUST NOT delare any of the Vulkan feature flags PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and PackageManager#FEATURE_VULKAN_HARDWARE_VERSION .

Chapter 7.9.2:

Android handheld device implementations MUST identify the support of high performance virtual reality for longer user periods through the android.hardware.vr.high_performance feature flag and meet the following requirements.

...

- Device implementations MUST support OpenGL ES 3.2.

- Device implementations MUST support Vulkan Hardware Level 0 and SHOULD support Vulkan Hardware Level 1.

....



Support depends on whether the GPU can handle compute shaders. That's a starting point.


No, the starting point is that Google doesn't require a Vulkan capable GPU on Android 7 devices, thus leaving everyone that cares about the size of customer base to keep using OpenGL ES.

If the engine needs two rendering interfaces, the effort is exactly the same as OpenGL ES + whatever else.

Unless you are suggesting game developers should be happy to sell only to LG V20, Samsung S7 and Google Pixel owners.


I'm talking about hardware capabilities. Actual support depends on the drivers. And why would Qualcomm, Imagination, Nvidia and etc. not want to provide them, if they can? Google has nothing to do with it (at least not in the sense of developing them).

Turnaround in the mobile hardware space is even faster than on the desktop (let alone stagnating consoles), so Vulkan availability is much less of an issue there.


The OEMs building those handsets get to choose which SOCs are used on those devices.

It doesn't matter if the drivers are available if those GPUs aren't on the motherboard.

Currently Vulkan is constrained to 2.8% of the Android market.

> Turnaround in the mobile hardware space is even faster than on the desktop (let alone stagnating consoles), so Vulkan availability is much less of an issue there.

Only in US, not everyone around the world, specially in countries where pre-pay is the way to go, changes their mobile every two years.


> It doesn't matter if the drivers are available if those GPUs aren't on the motherboard.

My point is, this situation will be shorter than on the desktop. Because as I said, the turnaround of mobile hardware is faster.

> ly in US, not everyone around the world, specially in countries where pre-pay is the way to go, changes their mobile every two years.

In US too, not everyone is going to buy every new model. I'm talking however about manufacturers making them. That happens pretty fast. So Vulkan support on new hardware is probably already a given and this whole thing is a non issue. Any new technology has adoption period.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: