1. 22 Mar, 2019 1 commit
    • Revert "Vulkan:Optimize SecondaryCommandBuffers" · 896e7811
      Jamie Madill authored
      This reverts commit 2219b18c.
      
      Reason for revert: Failing to compile on ASAN builders:
      
      https://ci.chromium.org/p/chromium/builders/try/linux-libfuzzer-asan-rel/134782
      
      Currently blocking roll.
      
      Original change's description:
      > Vulkan:Optimize SecondaryCommandBuffers
      > 
      > Optimize performance of SecondaryCommandBuffers and enable them as the
      > default build option.
      > To disable this set angle_enable_custom_vulkan_cmd_buffers=false in
      > your build args.
      > 
      > This CL enhances the PoolAllocator to have a "fast" mode that can
      > be enabled at class creation. This mode uses an alignment of 1 byte and
      > enables a fastAllocation() call that avoids some bookkeeping overhead.
      > The SecondaryCommandBuffer uses this fastAllocation() function.
      > Furthermore the fast path of fast allocate, using the current page,
      > is inlined for maximum speed.
      > Jamie Madill also updated the SecondaryCommandBuffers to pre-allocate
      > blocks so that the commands occur linearly in memory. This speeds up
      > processing with improved cache coherency and minimizes overhead when
      > recording commands.
      > Also the core Draw functions and their state updates are all inlined
      > as well as the common functions to initialize commands and to copy
      > command pointer data.
      > 
      > This change also includes some new, custom commands. One is
      > imageBarrier that is a specialized version of pipelineBarrier that only
      > performs a single image layout transition.
      > There are customized versions of various Draw commands to minimize
      > copying of parameters.
      > There are also specialized commands to bind[Graphics|Compute]Pipeline
      > that have the pipeline type built in to the command.
      > More custom commands and command data size optimizations will be made
      > in follow-on commits.
      > 
      > Bug: angleproject:3136
      > Change-Id: I35453cc2656bc8c51f0d84d1adef106900aca9a5
      > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1497418
      > Commit-Queue: Tobin Ehlis <tobine@google.com>
      > Reviewed-by: Jamie Madill <jmadill@chromium.org>
      
      TBR=tobine@google.com,syoussefi@chromium.org,jmadill@chromium.org
      
      Change-Id: I1c0bfe864ff343eb8ea6c88556523f8715c981d5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: angleproject:3136
      Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1535998Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Commit-Queue: Jamie Madill <jmadill@chromium.org>
  2. 21 Mar, 2019 12 commits
  3. 20 Mar, 2019 7 commits
  4. 19 Mar, 2019 5 commits
  5. 18 Mar, 2019 6 commits
  6. 16 Mar, 2019 4 commits
  7. 15 Mar, 2019 4 commits
  8. 14 Mar, 2019 1 commit
    • Vulkan: Fix CommandGraph barrier nodes w.r.t to first node · 2fb6563b
      Shahbaz Youssefi authored
      The barrier dependencies were set in two loops:
      
      - From Previous to (Previous, Current]
      - From (Previous, Current) to Current
      
      The "Previous to Current" dependency was set in the first loop.  This
      loop is conditioned to a previous barrier existing at all.
      
      The bug is that for the first barrier node, the first loop does not
      execute and the second loop does not create the dependency from the
      first node (Previous index being 0 when no previous barrier exists) to
      the barrier node.
      
      Bug: angleproject:2361
      Change-Id: I61a78dbbeba6cf97788bf8ea32908c7865ad48c2
      Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1520994
      Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>