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>
ANGLE’s Vulkan back-end implementation lives in this folder.
Vulkan is an explicit graphics API. Compared to APIs like OpenGL or D3D11 explicit APIs can offer a number of significant benefits:
The vk::Renderer class represents an EGLDisplay. vk::Renderer owns shared global
resources like the VkDevice, VkQueue, the Vulkan format tables
and internal Vulkan shaders. The ContextVk class implements the back-end
of a front-end OpenGL Context. ContextVk processes state changes and handles action commands like
glDrawArrays and glDrawElements.
A render pass has three states: unstarted, started and active (we call it active in short),
started but inactive (we call it inactive in short). The back-end records commands into command
buffers via the following ContextVk APIs:
beginNewRenderPass: Writes out (aka flushes) prior pending commands into a primary command
buffer, then starts a new render pass. Returns a secondary command buffer inside a render pass
instance. getOutsideRenderPassCommandBuffer: May flush prior command buffers and close the render pass if
necessary, in addition to issuing the appropriate barriers. Returns a secondary command buffer
outside a render pass instance. getStartedRenderPassCommands: Returns a reference to the currently open render pass’ commands
buffer. onRenderPassFinished: Puts render pass into inactive state where you can not record more
commands into secondary command buffer, except in some special cases where ANGLE does some
optimization internally. flushCommandsAndEndRenderPassWithoutSubmit: Marks the end of render pass. It flushes secondary
command buffer into vulkan’s primary command buffer, puts secondary command buffer back to
unstarted state and then goes into recycler for reuse.
The back-end (mostly) records Image and Buffer barriers through additional CommandBufferAccess
APIs, the result of which is passed to getOutsideRenderPassCommandBuffer. Note that the barriers
are not actually recorded until getOutsideRenderPassCommandBuffer is called:
onBufferTransferRead and onBufferComputeShaderRead accumulate VkBuffer read barriers. onBufferTransferWrite and onBufferComputeShaderWrite accumulate VkBuffer write barriers. onBuffferSelfCopy is a special case for VkBuffer self copies. It behaves the same as write. onImageTransferRead and onImageComputerShadeRead accumulate VkImage read barriers. onImageTransferWrite and onImageComputerShadeWrite accumulate VkImage write barriers. onImageRenderPassRead and onImageRenderPassWrite accumulate VkImage barriers inside a
started RenderPass.
After the back-end records commands to the primary buffer and we flush (e.g. on swap) or when we call
vk::Renderer::finishQueueSerial, ANGLE submits the primary command buffer to a VkQueue.
See the code for more details.
In this example we’ll be recording a buffer copy command:
// Ensure that ANGLE sets proper read and write barriers for the Buffers.
vk::CommandBufferAccess access;
access.onBufferTransferWrite(dstBuffer);
access.onBufferTransferRead(srcBuffer);
// Get a pointer to a secondary command buffer for command recording.
vk::OutsideRenderPassCommandBuffer *commandBuffer;
ANGLE_TRY(contextVk->getOutsideRenderPassCommandBuffer(access, &commandBuffer));
// Record the copy command into the secondary buffer. We're done!
commandBuffer->copyBuffer(srcBuffer->getBuffer(), dstBuffer->getBuffer(), copyCount, copies);
More implementation details can be found in the doc directory: