Branch
Hash :
f0370a41
Author :
Date :
2025-09-09T19:44:57
Vulkan: Use the GENERAL layout if VK_KHR_unified_image_layouts This lets ANGLE simplify synchronization by generally being able to use memory barriers instead of listing image barriers separately. Although the more specific access masks from VK_KHR_synchronization2 is possibly necessary for some hardware to work optimally (VK_ACCESS_2_SHADER_SAMPLED_READ_BIT in particular). It also lets ANGLE optimize a very specific scenario. Take an image used in the following scenario: 1. Copy to image in a transfer operation 2. Sample from image in the fragment shader of render pass 1 3. Sample from image in the vertex shader of shader pass 2 When GENERAL is not used, there's a layout transition between steps 1 and 2, changing the layout from TRANSFER_DST to SHADER_READ_ONLY_OPTIMAL (with dst stage == fragment shader). Later, at step 3, we need to make sure the vertex shader at least waits for this layout transition to finish... a dependency which is not expressible in Vulkan: * There cannot be a dependency to step 1, because the layout transition is not necessarily done * There is no stage mask that signifies the end of a layout transition. Without GENERAL, ANGLE has no choice but to issue a fragment->vertex dependency before step 3, serializing render pass 2's vertex pass with render pass 1's fragment pass on tilers. When using the GENERAL layout instead, step 3 can issue a transfer->vertex memory barrier, including using a VkEvent, parallelizing the two render passes. The above optimization is possible after this change, but not yet implemented. Bug: angleproject:422982681 Change-Id: Ieaae6f92b8b7d1e9c80c810a759c64b1e81d2dc1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6936485 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
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
Name
ANGLE_vulkane_image
Name Strings
GL_ANGLE_vulkane_image
Contributors
Peng Huang, Google
Contact
Peng Huang, Google (penghuang 'at' chromium.com)
Status
Draft
Version
Last Modified Date: Nov 19, 2021
Revision: 1
Number
TBD
Dependencies
Written against the OpenGL 4.5 and OpenGL ES 3.2 specifications
GL_ANGLE_vulkane_image requires GL_EXT_external_objects
Overview
Building upon the OpenGL memory object and semaphore framework
defined in EXT_external_objects, this extension enables an OpenGL
application to share textures with an external API.
New Procedures and Functions
If the GL_ANGLE_vulkane_image string is reported, the following commands
are added:
void AcquireTexturesANGLE(uint numTextures,
const uint *textures,
const GLenum *layouts);
void ReleaseTexturesANGLE(uint numTextures,
const uint *textures,
GLenum *layouts);
New Tokens
None
Additions to Chapter 4 of the OpenGL 4.5 Specification (Event Model)
The command
void AcquireTexturesANGLE(uint numTextures,
const uint *textures,
const GLenum *layouts);
will acquire ownership of textures. Since the texture layout state is
managed internally by the GL, but may have been modified by an external API,
the current layout of the textures must be specified to initialize internal
GL state prior to correspond to those specified by the Vulkan API as
described in table 4.4. However, the layouts do not necessarily correspond
to an optimal state for any particular GL operation. The GL will simply
perform appropriate transitions internally as necessary based on the
specified current layout of the texture.
When ANGLE uses VK_KHR_unified_image_layouts, the Vulkan stage and access
masks for each texture continue to be derived from the layouts parameter
and used for synchronization purposes, but the actual Vulkan layout of the
images must be VK_IMAGE_LAYOUT_GENERAL.
The command
void ReleaseTexturesANGLE(uint numTextures,
const uint *textures,
GLenum *layouts);
will release ownership of textures. The current texture layouts will be
returned, so an external API can perform appropriate transitions as
necessary based on the returned current layout of the textures.
Revision History
Revision 1, 2021-11-19 (Peng Huang)
- Initial draft based closely on EXT_external_objects_fd.