Hash :
410d8ba5
Author :
Date :
2022-12-21T13:27:00
Vulkan: Cleanup ContextVk::hasStartedRenderPass APIs ContextVk has a few hasStartedRenderPass APIs which interpret "start" inconsistently. A RenderPassCommands' life should be notStarted, started, requestEnd, and end (which is equivalent to notStarted). When someone calls onRenderPassFinished on a started renderpass, it does not immediate endRenderPass, but it will set DIRTY_BIT_RENDER_PASS dirty bit so that next draw call will trigger endRenderPass and start a new renderPass. We do not have a name for this state, which adds some confusion. This CL renames the stage between start and onRenderPassFinished to be "active" renderpass, when you have mRenderPassCommandBuffer pointer being valid and you can actively adding draw commands into the renderPass. For this purpose, I haves renamed hasStartedRenderPass to hasActiveRenderPass. This CL also simplifies hasStartedRenderPass implementation to only check mRenderPassCommandBuffer and turned mRenderPassCommands.started as assertion. This CL also changes hasStartedRenderPassWithQueueSerial to actually check mRenderPassCommands.started instead of being "active", so that name reflects what it is actually checking. This CL also changed hasStartedRenderPassWithCommands to hasActiveRenderPassWithCommands to make name and implementation consistent. One added benefit of this is that after this CL we now allow load/store optimization on a started but inactive renderPass as well (for example glInvalidateFramebuffer call after glFenceSync call, or invalidate after FBO blit as demonstrated by MultisampleResolveTest.ResolveD32FSamples tests). Bug: angleproject:7903 Bug: angleproject:7551 Change-Id: I8c8ec4c0d54b9ad0a9e373108dfce6b151c8fe0e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119693 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
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.
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
RendererVk::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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
# ANGLE: Vulkan Back-end
ANGLE's Vulkan back-end implementation lives in this folder.
[Vulkan](https://www.khronos.org/vulkan/) is an explicit graphics API. It has a lot in common with
other explicit APIs such as Microsoft's [D3D12][D3D12 Guide] and Apple's
[Metal](https://developer.apple.com/metal/). Compared to APIs like OpenGL or D3D11 explicit APIs can
offer a number of significant benefits:
* Lower API call CPU overhead.
* A smaller API surface with more direct hardware control.
* Better support for multi-core programming.
* Vulkan in particular has open-source tooling and tests.
[D3D12 Guide]: https://docs.microsoft.com/en-us/windows/desktop/direct3d12/directx-12-programming-guide
## Back-end Design
The [`RendererVk`](RendererVk.cpp) class represents an `EGLDisplay`. `RendererVk` owns shared global
resources like the [VkDevice][VkDevice], [VkQueue][VkQueue], the [Vulkan format tables](vk_format_utils.h)
and [internal Vulkan shaders](shaders). The [ContextVk](ContextVk.cpp) class implements the back-end
of a front-end OpenGL Context. ContextVk processes state changes and handles action commands like
`glDrawArrays` and `glDrawElements`.
## Command recording
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
`RendererVk::finishQueueSerial`, ANGLE submits the primary command buffer to a `VkQueue`.
See the [code][CommandAPIs] for more details.
### Simple command recording example
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);
```
## Additional Reading
More implementation details can be found in the `doc` directory:
- [Fast OpenGL State Transitions](doc/FastOpenGLStateTransitions.md)
- [Shader Module Compilation](doc/ShaderModuleCompilation.md)
- [OpenGL Line Segment Rasterization](doc/OpenGLLineSegmentRasterization.md)
- [Format Tables and Emulation](doc/FormatTablesAndEmulation.md)
- [Deferred Clears](doc/DeferredClears.md)
- [Queries](doc/Queries.md)
[VkDevice]: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDevice.html
[VkQueue]: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkQueue.html
[CommandAPIs]: https://chromium.googlesource.com/angle/angle/+/df31624eaf3df986a0bdf3f58a87b79b0cc8db5c/src/libANGLE/renderer/vulkan/ContextVk.h#620