Hash :
dd4e09ef
Author :
Date :
2020-03-20T14:54:36
Update conditions for exposing ASTC extensions. Add commenents to explain the Vulkan ASTC situation. Expose GL_KHR_texture_compression_astc_sliced_3d when the HDR profile exists. Bug: angleproject:4447 Change-Id: I00a86cb3c44873a28397aab33a47fb363d4ecfe9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2112283 Reviewed-by: Alexis Hétu <sugoi@chromium.org> Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com> Commit-Queue: Geoff Lang <geofflang@chromium.org>
ANGLE’s Vulkan back-end implementation lives in this folder.
Vulkan is an explicit graphics API. It has a lot in common with other explicit APIs such as Microsoft’s D3D12 and Apple’s Metal. Compared to APIs like OpenGL or D3D11 explicit APIs can offer a number of significant benefits:
The RendererVk class represents an EGLDisplay. RendererVk 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.
The back-end records commands into command buffers via the the following ContextVk APIs:
endRenderPassAndGetCommandBuffer: returns a secondary command buffer outside a RenderPass instance. flushAndBeginRenderPass: returns a secondary command buffer inside a RenderPass instance. flushAndGetPrimaryCommandBuffer: returns the primary command buffer. You should rarely need this API.
Note: All of these commands may write out (aka flush) prior pending commands into a primary
command buffer. When a RenderPass is open endRenderPassAndGetCommandBuffer will flush the
pending RenderPass commands. flushAndBeginRenderPass will flush out pending commands outside a
RenderPass to a primary buffer. On submit ANGLE submits the primary command buffer to a VkQueue.
If you need to record inside a RenderPass, use flushAndBeginRenderPass. Otherwise, use
endRenderPassAndGetCommandBuffer. You should rarely need to call flushAndGetPrimaryCommandBuffer.
It’s there for commands like debug labels, barriers and queries that need to be recorded serially on
the primary command buffer.
The back-end usually records Image and Buffer barriers through additional ContextVk APIs:
onBufferRead and onBufferWrite accumulate VkBuffer barriers. onImageRead and onImageWrite accumulate VkImage barriers. onRenderPassImageWrite is a special API for write barriers inside a RenderPass instance.
After the back-end records commands to the primary buffer we flush (e.g. on swap) or when we call
ContextVk::finishToSerial.
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.
ANGLE_TRY(contextVk->onBufferWrite(VK_ACCESS_TRANSFER_WRITE_BIT, destBuffer));
ANGLE_TRY(contextVk->onBufferRead(VK_ACCESS_TRANSFER_READ_BIT, srcBuffer));
# Get a pointer to a secondary command buffer for command recording. May "flush" the RP.
vk::CommandBuffer *commandBuffer;
ANGLE_TRY(contextVk->endRenderPassAndGetCommandBuffer(&commandBuffer));
# Record the copy command into the secondary buffer. We're done!
commandBuffer->copyBuffer(srcBuffer->getBuffer(), destBuffer->getBuffer(), copyCount, copies);
More implementation details can be found in the doc directory: