tree: 29a9373602eba5dfeee38bc65e4d97e211e89533
  1. android/
  2. doc/
  3. fuchsia/
  4. linux/
  5. mac/
  6. null/
  7. shaders/
  8. win32/
  9. AllocatorHelperPool.cpp
  10. AllocatorHelperPool.h
  11. BufferVk.cpp
  12. BufferVk.h
  13. BUILD.gn
  14. cl_types.h
  15. CLCommandQueueVk.cpp
  16. CLCommandQueueVk.h
  17. CLContextVk.cpp
  18. CLContextVk.h
  19. CLDeviceVk.cpp
  20. CLDeviceVk.h
  21. CLEventVk.cpp
  22. CLEventVk.h
  23. CLKernelVk.cpp
  24. CLKernelVk.h
  25. CLMemoryVk.cpp
  26. CLMemoryVk.h
  27. CLPlatformVk.cpp
  28. CLPlatformVk.h
  29. CLProgramVk.cpp
  30. CLProgramVk.h
  31. CLSamplerVk.cpp
  32. CLSamplerVk.h
  33. clspv_utils.cpp
  34. clspv_utils.h
  35. CommandQueue.cpp
  36. CommandQueue.h
  37. CompilerVk.cpp
  38. CompilerVk.h
  39. ContextVk.cpp
  40. ContextVk.h
  41. DebugAnnotatorVk.cpp
  42. DebugAnnotatorVk.h
  43. DeviceVk.cpp
  44. DeviceVk.h
  45. DisplayVk.cpp
  46. DisplayVk.h
  47. DisplayVk_api.h
  48. DriverUniforms.h
  49. FenceNVVk.cpp
  50. FenceNVVk.h
  51. FramebufferVk.cpp
  52. FramebufferVk.h
  53. gen_vk_format_table.py
  54. gen_vk_internal_shaders.py
  55. gen_vk_mandatory_format_support_table.py
  56. ImageVk.cpp
  57. ImageVk.h
  58. MemoryObjectVk.cpp
  59. MemoryObjectVk.h
  60. MemoryTracking.cpp
  61. MemoryTracking.h
  62. OWNERS
  63. PersistentCommandPool.cpp
  64. PersistentCommandPool.h
  65. ProgramExecutableVk.cpp
  66. ProgramExecutableVk.h
  67. ProgramPipelineVk.cpp
  68. ProgramPipelineVk.h
  69. ProgramVk.cpp
  70. ProgramVk.h
  71. QueryVk.cpp
  72. QueryVk.h
  73. README.md
  74. RenderbufferVk.cpp
  75. RenderbufferVk.h
  76. RenderTargetVk.cpp
  77. RenderTargetVk.h
  78. SamplerVk.cpp
  79. SamplerVk.h
  80. SecondaryCommandBuffer.cpp
  81. SecondaryCommandBuffer.h
  82. SecondaryCommandPool.cpp
  83. SecondaryCommandPool.h
  84. SemaphoreVk.cpp
  85. SemaphoreVk.h
  86. ShaderInterfaceVariableInfoMap.cpp
  87. ShaderInterfaceVariableInfoMap.h
  88. ShaderVk.cpp
  89. ShaderVk.h
  90. ShareGroupVk.cpp
  91. ShareGroupVk.h
  92. spv_utils.cpp
  93. spv_utils.h
  94. Suballocation.cpp
  95. Suballocation.h
  96. SurfaceVk.cpp
  97. SurfaceVk.h
  98. SyncVk.cpp
  99. SyncVk.h
  100. TextureVk.cpp
  101. TextureVk.h
  102. TransformFeedbackVk.cpp
  103. TransformFeedbackVk.h
  104. UtilsVk.cpp
  105. UtilsVk.h
  106. VertexArrayVk.cpp
  107. VertexArrayVk.h
  108. vk_barrier_data.cpp
  109. vk_barrier_data.h
  110. vk_cache_utils.cpp
  111. vk_cache_utils.h
  112. vk_caps_utils.cpp
  113. vk_caps_utils.h
  114. vk_cl_utils.cpp
  115. vk_cl_utils.h
  116. vk_command_buffer_utils.h
  117. vk_format_map.json
  118. vk_format_table_autogen.cpp
  119. vk_format_utils.cpp
  120. vk_format_utils.h
  121. vk_helpers.cpp
  122. vk_helpers.h
  123. vk_internal_shaders_autogen.cpp
  124. vk_internal_shaders_autogen.gni
  125. vk_internal_shaders_autogen.h
  126. vk_mandatory_format_support_data.json
  127. vk_mandatory_format_support_table_autogen.cpp
  128. vk_mem_alloc_wrapper.cpp
  129. vk_mem_alloc_wrapper.h
  130. vk_ref_counted_event.cpp
  131. vk_ref_counted_event.h
  132. vk_renderer.cpp
  133. vk_renderer.h
  134. vk_resource.cpp
  135. vk_resource.h
  136. vk_utils.cpp
  137. vk_utils.h
  138. vk_wrapper.h
  139. VkImageImageSiblingVk.cpp
  140. VkImageImageSiblingVk.h
  141. vulkan_backend.gni
  142. VulkanSecondaryCommandBuffer.cpp
  143. VulkanSecondaryCommandBuffer.h
src/libANGLE/renderer/vulkan/README.md

ANGLE: Vulkan Back-end

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:

  • 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.

Back-end Design

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.

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 CommandResources 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.

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::CommandResources resources;
    resources.onBufferTransferWrite(dstBuffer);
    resources.onBufferTransferRead(srcBuffer);

    // Get a pointer to a secondary command buffer for command recording.
    vk::OutsideRenderPassCommandBuffer *commandBuffer;
    ANGLE_TRY(contextVk->getOutsideRenderPassCommandBuffer(resources, &commandBuffer));

    // Record the copy command into the secondary buffer. We're done!
    commandBuffer->copyBuffer(srcBuffer->getBuffer(), dstBuffer->getBuffer(), copyCount, copies);

Handling EGL image offsets

A Texture can have a number of levels and layers. An EGL image may be created out of the texture, viewing a specific level and layer specified by EGL_GL_TEXTURE_LEVEL_KHR and EGL_GL_TEXTURE_ZOFFSET_KHR. The EGL image can then be imported into another texture whose own state does not include these offsets (e.g. the texture is accessed at level 0). It may similarly be imported into a renderbuffer that doesn't even have a level and layer state.

The TextureVk and RenderbufferVk classes use gl::OwnLevel, gl::OwnLayer, and gl::OwnImageIndex to refer to the level and layer from the point of view of the texture/renderbuffer itself, i.e. these values will be 0 for an EGL image target. When these values are needed as integers, e.g. to access an array, they are retrieved via getUntranslated().

However, any references outside these classes to levels and layers, i.e. those that are paired with VkImage and VkImageView, must use the source texture's original level and layer. This is done via the mState.toSource*() helpers, which return a strongly typed gl::SourceLevel, gl::SourceLayer and gl::SourceImageIndex. The level and layer can be retrieved from these types with a get().

Ideally, all the code in the front-end would use gl::Own* types and all the code in the backend outside these classes would use gl::Source* for maximum safety, where the compiler ensures there are no mistakes. This is not yet done, but in the meantime, any reference to level and layer in the front-end is implicitly from the point of view of the texture/renderbuffer itself (i.e. equivalent to gl::Own*). Any such reference outside TextureVk and RenderbufferVk in the backend is implicitly from the point of view of the owner of the VkImage (i.e. equivalent to gl::Source*).

The code in TextureVk and RenderbufferVk must always use mState.toSource* to convert the types before using a level or layer in conjunction with an ImageHelper, ImageViewHelper, RenderTargetVk, UtilsVk etc calls.

Additional Reading

More implementation details can be found in the doc directory: