1. 20 May, 2020 5 commits
  2. 19 May, 2020 10 commits
  3. 18 May, 2020 1 commit
    • Revert "Vulkan: Try to merge barriers if possible" · 8a90905c
      Charlie Lao authored
      This reverts commit 153c14cb.
      
      Reason for revert: The dependencyStrongerThan logic is incorrect and causing perf regression on ARM.
      
      Original change's description:
      > Vulkan: Try to merge barriers if possible
      >
      > This is try to reduce the number of vkCmdPipelineBarrier API calls into
      > driver. It should not affect the actual barriers.
      >
      > Bug: b/155341891
      > Change-Id: I57b8b8cdad50d494c76a008006bd54961170c8bc
      > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2194841
      > Commit-Queue: Charlie Lao <cclao@google.com>
      > Reviewed-by: Jamie Madill <jmadill@chromium.org>
      > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
      
      TBR=courtneygo@google.com,timvp@google.com,syoussefi@chromium.org,jmadill@chromium.org,cclao@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: b/155341891
      Change-Id: I8ebe7481b299af446dfd488874e64e6e60b4f764
      
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Change-Id: I8ebe7481b299af446dfd488874e64e6e60b4f764
      Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2205433
      Commit-Queue: Charlie Lao <cclao@google.com>
      Reviewed-by: 's avatarCharlie Lao <cclao@google.com>
  4. 16 May, 2020 2 commits
    • Vulkan: Save linked ProgramExecutable data · d34ab323
      Tim Van Patten authored
      PPOs need to support drawing with Programs that failed their last
      linkProgram() if they had previously successfully linked. This requires
      saving the ProgramExecutable when linkProgram() succeeds, and not
      overwriting it with subsequent linkProgram() calls unil the next
      successful one.
      
      To achieve this, the new member ProgramState::mLinkedExecutable will
      point to the last successfully linked ProgramExecutable and
      ProgramState::mExecutable will point to a new ProgramExecutable when the
      next linkProgram() is attempted. If the link fails, the newly allocated
      ProgramExecutable will be delete()'ed and mExecutable will point to the
      previous 'good' ProgramExecutable still being tracked by
      mLinkedExecutable. If it succeeds, the old mLinkedExecutable will be
      delete()'ed and mLinkedExecutable will be updated to point to the ne
      one.
      
      Bug: angleproject:4514
      Test: KHR-GLES31.core.sepshaderobjs.StateInteraction
      Change-Id: I0677602a6d652a055404667ec9e9305fed5b4177
      Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2181450
      Commit-Queue: Tim Van Patten <timvp@google.com>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
    • Resolve Bad Binary Link Failures · 5d01d538
      Rafael Cintron authored
      When ANGLE_PROGRAM_BINARY_LOAD is enabled, Program::loadBinary
      unconditionally returns angle::Result::Continue to the caller. The
      caller, gl::Program::link, postpones the resolution of the link
      until resolveLinkImpl.
      
      Unfortunately, resolveLinkImpl is not able to tell whether the link
      failed because the shader from the developer is bad or because the
      loaded binary is not compatible with the backend. The former case
      should fail link. In the latter case, we should fallback to linking
      the program from the original shader sources. The loaded binary could
      be read from the on-disk shader cache and be corrupted or serialized
      with different revision and subsystem id than the currently loaded
      ANGLE backend.
      
      This fix adjusts Program::loadBinary and ProgramD3D::load so that
      angle::Result::Incomplete is returned to gl::Program::link when the
      binary is incompatible with the backend.  gl::Program:link falls back
      to compilation from original shader sources.
      
      Since no code checks the return value of SizedMRUCache::eraseByKey,
      modified it to now return void.
      
      Bug: chromium:1079497
      Change-Id: Id5271d7badad8627563e87859d1c9fdb81de5785
      Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2197944Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Reviewed-by: 's avatarTim Van Patten <timvp@google.com>
      Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
  5. 15 May, 2020 13 commits
  6. 14 May, 2020 9 commits