1. 24 Feb, 2021 5 commits
  2. 22 Feb, 2021 4 commits
  3. 20 Feb, 2021 4 commits
  4. 19 Feb, 2021 8 commits
  5. 18 Feb, 2021 7 commits
  6. 17 Feb, 2021 3 commits
  7. 16 Feb, 2021 5 commits
  8. 12 Feb, 2021 2 commits
    • Support querying for Vulkan11 properties · 539ef8e9
      Sean Risser authored
      Vulkan 1.2 added VkPhysicalDeviceVulkan11Properties, which allows users
      to query support for several other device properties all together. We
      can use templated static functions to make sure these properties are
      only ever set in one place, similar to what we do for device features.
      
      The only struct this doesn't work for is
      VkPhysicalDeviceSubgroupProperties, because the names in that struct
      and the Vulkan11 struct differ. So the Vulkan11 struct manually copies
      the data from the getProperties(*) function for the subgroup properties.
      
      Bug: b/176248217
      Change-Id: I30e9e05ecbdb9a40fc3a59df6bd9b8ab9022c9fc
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51388Tested-by: 's avatarSean Risser <srisser@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
      Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Commit-Queue: Sean Risser <srisser@google.com>
    • Implement GLSLstd450Interpolate* functions · 0bcb71f9
      Alexis Hetu authored
      This cl adds an implementation for:
      - GLSLstd450InterpolateAtCentroid
      - GLSLstd450InterpolateAtSample
      - GLSLstd450InterpolateAtOffset
      
      These functions essentially replicate the behavior of
      regular interpolants in the fragment shader processing.
      
      A specific extra difficulty encountered here is detecting
      which kind of pointer offset we are dealing with. Pointer
      offsets might be caused by [] operators being used on a
      vector or on an array (possibly an array of vectors). This
      distinction is important as it impacts what interpolant
      offsets point to. Note that there's missing coverage in
      dEQP-VK for interpolant arrays and this was caught with
      SwANGLE tests (a dEQP-VK issue will be logged shortly).
      
      Another issue was dealing with dynamic interpolant offsets,
      which was solved by looping over all of them and combining
      all plane equations into one before performing the
      interpolation.
      
      Bug: b/171415086
      Change-Id: Id7c4c931918ba172d00da84655051445b110d3a9
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/51737
      Presubmit-Ready: Alexis Hétu <sugoi@google.com>
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarAlexis Hétu <sugoi@google.com>
      Commit-Queue: Alexis Hétu <sugoi@google.com>
      Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
  9. 10 Feb, 2021 2 commits
    • Unify load/store operand accessors · 673a7fe5
      Nicolas Capens authored
      Load and store instructions, as well as intrinsics which access memory,
      can now shared the same methods for accessing the memory address and
      data operands.
      
      Note that while this change introduces the potential for non-load/store
      instructions to have their operands accessed through getLoadAddress(),
      getStoreAddress(), or getData(), that risk isn't any greater than using
      the wrong getSrc() index, and would stick out as a mistake much more
      clearly. The advantage this change brings is that we no longer have to
      remember where the address and data operands are stored in sub-vector
      load/store intrinsics. In addition, there are no more overly verbose
      casts, and their cost is eliminated.
      
      Bug: b/179497998
      Change-Id: I0d9208555e00b0d3053f7d3baca241fef2b8cbeb
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52531
      Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>
    • Discern between load and store addresses · 8d50b556
      Nicolas Capens authored
      There were InstLoad::getSourceAddress() and InstStore::getAddr()
      methods, which aren't very clear and consistently named. This change
      replaces them with getLoadAddress() and getStoreAddress(), respectively.
      
      This will also enable moving these methods to the Inst class to make
      them available for SubVectorLoad and SubVectorStore intrinsics. While
      these methods don't make sense for other instructions, note that
      Inst::getSrc() already provides access to all operands and has to be
      used with knowledge of the operand meaning and layout. So this only
      provides a name to these operands, and it would stick out as a sore
      thumb if used incorrectly.
      
      Bug: b/179497998
      Change-Id: I86b1201b8a1c611682f4f91541bdb49e17ef71a8
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52530
      Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>