kc3-lang/angle/extensions/ANGLE_vulkan_image.txt

Branch - branch -main

• Show log

  Commit

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

Download

• extensions/ANGLE_vulkan_image.txt

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

Download