No OVR_multiview(2) in GL_EXTENSIONS on Android

[Andrew Sumsion]

I built ANGLE for android using the instructions here, along with the angle_expose_non_conformant_extensions_and_versions flag to hopefully get as much compatibility as possible. I installed it using the built APK on an AVD running Android 15 (Google APIs) and it works really well. The only problem is that the extensions OVR_multiview and OVR_multiview2 are missing, which is critical for what I'm working on.

I've made a simple app that just spits out the GL_RENDERER and GL_EXTENSIONS and I've confirmed that it's using ANGLE. I also made sure it's using a GLES 3.2 context.

Does anyone have any idea why the extensions aren't showing up? I can provide the source for my app that displays the extensions if needed.

[Shahbaz Youssefi]

Hi,

I'm assuming you are using the Vulkan backend of ANGLE. For every extension, there are conditions that need to be met, and it seems that on your device some condition for OVR_multiview isn't being met. You can find these conditions in [1], and the "features" they depend on initialized in [2]. For OVR_multiview in particular:

mNativeExtensions.multiviewOVR = mFeatures.supportsMultiview.enabled && mFeatures.bresenhamLineRasterization.enabled;

and

ANGLE_FEATURE_CONDITION(&mFeatures, supportsMultiview, mMultiviewFeatures.multiview == VK_TRUE);

ANGLE_FEATURE_CONDITION(&mFeatures, bresenhamLineRasterization, mLineRasterizationFeatures.bresenhamLines == VK_TRUE);

So it looks like either the `multiview` Vulkan feature is false on your platform, or bresenham lines are not supported. I'm not familiar with AVD, what does `adb shell cmd gpu vkjson` return on this device?

[1]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/src/libANGLE/renderer/vulkan/vk_caps_utils.cpp;l=321;drc=323187d9bca7417df9739c7f34f3aff970f2f264

[2]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/src/libANGLE/renderer/vulkan/vk_renderer.cpp;l=4545;drc=323187d9bca7417df9739c7f34f3aff970f2f264

[Andrew Sumsion]

Thank you for your help! By AVD I meant an Android Virtual Device in the official AOSP emulator. My first thought would be that the current version of gfxstream being used to forward vulkan to the host doesn't support multiview, but when I ran the command you suggested, it looks like it might?

Below is the output I got from `adb shell cmd gpu vkjson` with the irrelevant parts removed.

It looks like multiviewFeatures.multiview is supported.

I'm just brainstorming here, but I wonder if this is an unusual environment where the VK_KHR_multiview extension is absent but it still supports the functionality because it was promoted to Vulkan 1.1. I have no idea if that's actually unusual though.

```

{
"_comment" : "vkjson is deprecated, and will be replaced in a future release",
"apiVersion" : 4206592.0,
"deviceGroups" :
[
{
"devices" :
[
0.0
],
"subsetAllocation" : 0.0
}
],
"devices" :
[
...
{
"multiviewFeatures" :
{
"multiview" : 1.0,
"multiviewGeometryShader" : 0.0,
"multiviewTessellationShader" : 1.0
},
"multiviewProperties" :
{
"maxMultiviewInstanceIndex" : 4294967295.0,
"maxMultiviewViewCount" : 6.0
}
}
...
],
"extensions" :
[
{
"extensionName" : "VK_KHR_surface",
"specVersion" : 25.0
},
{
"extensionName" : "VK_KHR_surface_protected_capabilities",
"specVersion" : 1.0
},
{
"extensionName" : "VK_KHR_android_surface",
"specVersion" : 6.0
},
{
"extensionName" : "VK_EXT_swapchain_colorspace",
"specVersion" : 4.0
},
{
"extensionName" : "VK_KHR_get_surface_capabilities2",
"specVersion" : 1.0
},
{
"extensionName" : "VK_GOOGLE_surfaceless_query",
"specVersion" : 2.0
},
{
"extensionName" : "VK_EXT_surface_maintenance1",
"specVersion" : 1.0
},
{
"extensionName" : "VK_EXT_debug_report",
"specVersion" : 10.0
},
{
"extensionName" : "VK_KHR_external_fence_capabilities",
"specVersion" : 1.0
},
{
"extensionName" : "VK_KHR_external_memory_capabilities",
"specVersion" : 1.0
},
{
"extensionName" : "VK_KHR_external_semaphore_capabilities",
"specVersion" : 1.0
},
{
"extensionName" : "VK_KHR_get_physical_device_properties2",
"specVersion" : 2.0
},
{
"extensionName" : "VK_EXT_debug_utils",
"specVersion" : 2.0
}
],
"layers" : []
}
```

[Andrew Sumsion]

I just realized I didn't consider that it could be missing the bresenham lines. The necessary extension is VK_EXT_line_rasterization, which the output from vkjson notably lacks. It looks like ANGLE checks for this feature by having a VkPhysicalDeviceLineRasterizationFeaturesEXT[1] struct filled in by vkGetPhysicalDeviceFeatures2. I can put together a quick little program to check that this is in fact returning false for bresenham lines and update this post to confirm.

For my use case, I can trade off perfect conformity with the spec for slightly different lines, so I may end up looking into modifying my copy to remove the dependence on bresenham lines.

[1]: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPhysicalDeviceLineRasterizationFeaturesEXT.html

On Saturday, October 19, 2024 at 7:33:06 PM UTC-6 syou...@chromium.org wrote:

[Andrew Sumsion]

I ended up getting it working, at least for the GL extensions to show up. I haven't tested them properly yet. I think I was initially correct that because VK_KHR_multiview is missing, it's disabling the multiview feature, even though that functionality is promoted into Vulkan 1.1. I filed a bug [1] and submitted a CL [2] to make enabling the features of promoted Vulkan extensions dependent on the extension being present, OR the proper version of Vulkan being present.

On my local copy (not in the CL) I wanted to get rid of the dependence on VK_KHR_line_rasterization, so I just commented out the check for the Bresenham lines. I at first thought this would cause issues with the Bresenham lines emulation like the comment above it says, but with some further investigation I think the Bresenham line emulation was removed entirely in 3b988fef3002eb532ed39c862eda55f5779d1fd8 in favor of the VK_KHR_line_rasterization extension. As soon as I get a chance to test it I'll see if it breaks something or if it just renders the lines differently.

[1]: https://issues.angleproject.org/issues/374483183

[2]: https://chromium-review.googlesource.com/c/angle/angle/+/5944678

On Saturday, October 19, 2024 at 7:33:06 PM UTC-6 syou...@chromium.org wrote:

[Shahbaz Youssefi]

Thank you, good job figuring it out and I appreciate the fix. You're right that lack of bresenham lines is probably not going to bother you in any realistic way. Unfortunately we have to depend on it for conformance. FWIW, bresenham lines should be quite ubiquitous by now, if gfxstream is the reason you don't get the extension, it'd be worth opening a ticket with them about it.

---

FYI, if you want to force enable/disable and ANGLE feature, you can do that without modifying the code. On desktop, that would be through the ANGLE_FEATURE_OVERRIDES_ENABLED=featureName1:featureName2 (disable with ANGLE_FEATURE_OVERRIDES_DISABLED). On Android, the command is similar:

$ adb shell setprop debug.angle.feature_overrides_enabled featureName1:featureName2  # disable with feature_overrides_disabled

So in your case, setting `debug.angle.feature_overrides_enabled` to `bresenhamLineRasterization` should do the trick (if you're willing to accept some VVL warnings about ANGLE using the ext without it being present ;). Features that indicate extension support are generally better not overridden to be enabled though, as you might imagine the results aren't always error-free.