• Show log

    Commit

  • Hash : 9475ac40
    Author : Shahbaz Youssefi
    Date : 2023-11-15T10:25:06

    Vulkan: Make efficient MSAA resolve possible
    
    Prior to this change, using a resolve attachment to implement resolve
    through glBlitFramebuffer was done by temporarily modifying the source
    FramebufferVk's framebuffer description.  This caused a good deal of
    complexity; enough to require the render pass to be immediately closed
    after this optimization.
    The downsides to this are:
    
    - Only one attachment can be efficiently resolved
    - There is no chance for the MSAA attachment to be invalidated
    
    In this change, resolve attachments that are added because of
    glBlitFramebuffer are stored in the command buffer, with the
    FramebufferVk completely oblivious to them.  When the render pass is
    closed, either the FramebufferVk's original framebuffer object is used
    (if no resolve attachments are added) or a temporary one is created to
    include those resolve attachments.
    
    With the above method, the render pass is able to accumulate many
    resolve attachments as well as have its MSAA attachments be invalidated
    before it is flushed.
    
    For a FramebufferVk that is resolved in this way, there used to be two
    framebuffers created each time and thrown away as the code alternated
    between starting a render pass without a resolve attachment and then
    closing with one.  With this change, there is now one framebuffer
    (without resolve attachments) that is cached in FramebufferVk (and is
    not recreated every time), and only the framebuffer with resolve
    attachments is recreated every time.
    
    Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there
    would be no framebuffers to create and destroy, and this change paves
    the way for that support too.
    
    WindowSurfaceVk framebuffers are still imagefull.  Making them imageless
    adds unnecessary complication with no benefit.
    
    -----------------
    
    To achieve efficient MSAA rendering on tiling hardware, applications
    should do the following:
    
    ```
    glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO);
    
    // Clear the framebuffer to avoid a load
    // Or invalidate, if not needed to load:
    // glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...);
    glClear(...);
    
    // Draw calls
    
    // Resolve into the single sampled framebuffer
    glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO);
    glBlitFramebuffer(...);
    // Immediately discard the contents of the MSAA buffer, to avoid store
    glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...);
    ```
    
    The above would translate to the following Vulkan render pass:
    
    - MSAA LOAD_OP_CLEAR/DONT_CARE
    - MSAA STORE_OP_DONT_CARE
    - Resolve LOAD_OP_DONT_CARE
    - Resolve STORE_OP_STORE
    
    This makes sure the MSAA data doesn't leave the tile memory and greatly
    reduces bandwidth usage.
    
    Once anglebug.com/4892 is fixed, this would also allow the MSAA image
    to never be allocated either.
    
    Bug: angleproject:7551
    Bug: angleproject:8625
    Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062
    Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492
    Reviewed-by: Yuxin Hu <yuxinhu@google.com>
    Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
    Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
    

  • Properties

  • Git HTTP https://git.kmx.io/kc3-lang/angle.git
    Git SSH git@git.kmx.io:kc3-lang/angle.git
    Public access ? public
    Description

    A conformant OpenGL ES implementation for Windows, Mac, Linux, iOS and Android.

    Homepage

    Github

    Users
    thodg_m kc3_lang_org thodg_w www_kmx_io thodg thodg_l
    Tags