Hash :
317f81db
Author :
Date :
2025-05-01T14:17:47
Fix EGL_RENDER_BUFFER query if EGL_SINGLE_BUFFER unsupported eglCreateWindowSurface() can have the EGL attribute EGL_RENDER_BUFFER specified: EGL_RENDER_BUFFER specifies which buffer should be used by default for client API rendering to the window, as described in section 2.2.2. If its value is EGL_SINGLE_BUFFER, then client APIs should render directly into the visible window. If its value is EGL_BACK_BUFFER, then all client APIs should render into the back buffer. The default value of EGL_RENDER_BUFFER is EGL_BACK_BUFFER. Client APIs may not be able to respect the requested rendering buffer. To determine the actual buffer that a context will render to by default, call eglQueryContext with attribute EGL_RENDER_BUFFER (see section 3.7.4). To support EGL_SINGLE_BUFFER, Vulkan surfaces must support the VkPresentModeKHR value VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR: VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR specifies that the presentation engine and application have concurrent access to a single image, which is referred to as a shared presentable image. The presentation engine is only required to update the current image after a new presentation request is received. Therefore the application must make a presentation request whenever an update is required. However, the presentation engine may update the current image at any point, meaning this mode may result in visible tearing. However, this is only available on Vulkan devices that support the extension VK_KHR_shared_presentable_image. Add checking in Surface::initialize() to update Surface::mRenderBuffer to EGL_BACK_BUFFER if the backend implementation does not support EGL_SINGLE_BUFFER. This includes adding supportsSingleRenderBuffer() to query the backend if it supports single render buffer mode, which defaults to False. The Vulkan backend overrides this and the result is based on support for VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR. Bug: b/412446258 Test: EGLLockSurface3Test.WindowMsaaSurfaceReadTest/ES2_Vulkan_NoFixture Test: EGLSingleBufferTest.VerifyMutableRenderBufferKHR/* Change-Id: I4e6d56f01a895a5bd887580e6ffa34d574c87fad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6506764 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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.