Hash :
1f5eb6b8
Author :
Date :
2021-11-17T16:42:20
Avoid Android vkEnumerateDeviceExtensionProperties() bug This works around a race-condition during Android start-up, when ANGLE is used as the default GLES driver and when render engine (RE) is using SkiaGL (which uses ANGLE, which uses Vulkan). The race condition occassionally results in different numbers of extensions between ANGLE's first and second calls to vkEnumerateDeviceExtensionProperties(). In that case, the second call would return VK_INCOMPLETE instead of VK_SUCCESS. That caused ANGLE to fail to initialize, causing RE to fail to initialize. This change works around this problem by increasing the number of extensions asked for in the second call to vkEnumerateDeviceExtensionProperties(). Background: Surface Flinger uses Hardware Composer (HWC) for hardware-based composition (e.g. using overlays), and RE for GPU composition (e.g. rendering to combine multiple app and system windows together). SF, RE, and HWC all start about the same time. HWC sets a property if it can support display timing. This gets passed through SF to RE's Vulkan loader. The Vulkan loader uses that property to determine whether to enable the VK_GOOGLE_display_timing extension. The Vulkan loader used to make a synchronous call to SF in vkEnumerateDeviceExtensionProperties() in order to get this property. That took some number of milliseconds to complete and affected the start-up time of every Vulkan/ANGLE app. To eliminate that performance problem, the property now propogates in an asynchronous manner. At that time, it was thought that RE would always get the property in time. However, a partner's experience is that VK_INCOMPLETE is happening 0.5% of the time. ANGLE doesn't need to use the VK_GOOGLE_display_timing extension. This is because the Android EGL loader provides the related EGL_ANDROID_get_frame_timestamps extension. The issue that ANGLE is working around is that it shouldn't fail to initialize in this situation. Bug: angleproject:6715 Bug: b/206733351 Change-Id: I4eb2197cdcc9692518b1bf5984d06fc8a1a7d145 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3290506 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
This folder contains shared back-end-specific implementation files. The classes
and types in renderer are not specified by GLES. They instead are common to
all the various ANGLE implementations.
See renderer_utils.h for various cross back-end utilties.
The ANGLE format class, angle::Format, works as a union
between GLES and all the various back-end formats. It can represent any type
of format in ANGLE. e.g. Formats in Vulkan that don’t exist in GLES, or DXGI
formats that don’t exist in GLES, or Windows/Android surface configs that
don’t exist anywhere else.
The glInternalFormat member of angle::Format represents the “closest” GL
format for an ANGLE format. For formats that don’t exist in GLES this will
not be exactly what the format represents.
The back-ends also define their own format tables. See the Vulkan Format table docs and the [D3D11 format table docs][D23D11FormatDocs].
DXGI formats are used in both the GL and D3D11 back-end. Therefore the generated info table lives in this common shared location.
The DXGI info table is generated by gen_dxgi_format_table.py
and sources data from dxgi_format_data.json. The
main purpose of the table is to convert from a DXGI format to an ANGLE
format, where the ANGLE format should have all the necessary information.