1. 12 May, 2021 2 commits
    • Work around MemorySanitizer scalar SSE false positives · c4d054c6
      Nicolas Capens authored
      Scalar SSE instructions only use the lowest scalar of an SSE vector
      register, but MemorySanitizer doesn't recognize some of them so it will
      check the entire 128-bit operand for uninitialized bits.
      
      This change makes sure the other elements of the vector gets zero-
      initialized instead of leaving it undefined. This affects Round, Trunc,
      Frac, Ceil, Floor, Sqrt, and RcpSqrt scalar operations.
      
      Note that this workaround results in MemorySanitizer marking the entire
      output vector to have a well-defined value, which isn't actually the
      case in non-MSan builds. Fortunately, a scalar can't be cast into a
      vector (unlike our 'emulated' small vectors), so we just have to make
      sure to immediately extract the scalar from the intrinsic's result.
      
      Bug: b/172238865
      Change-Id: If68388e476ac9e27e2de33ddf2efab4124540c7a
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/54269
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
    • Work around MemorySanitizer movmsk false positives · b162fcf9
      Nicolas Capens authored
      MemorySanitizer does not recognize the x86 movmskps and pmovmskb
      instructions. In such cases it falls back to checking all input operands
      for uninitialized bits. This causes false positives specifically with
      Reactor's Byte8 type which is often loaded from memory, leaving the
      upper 64-bit of an SSE register undefined.
      
      This change masks out the unused parts of the input vector, leaving just
      the sign bits.
      
      Bug: b/172238865
      Change-Id: I50c921a7ff8a4ebdba89136bb82c9f46ccdc3769
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/54268
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
  2. 11 May, 2021 1 commit
  3. 10 May, 2021 3 commits
  4. 07 May, 2021 1 commit
  5. 06 May, 2021 2 commits
  6. 05 May, 2021 4 commits
  7. 28 Apr, 2021 1 commit
  8. 22 Apr, 2021 1 commit
    • Format switch statements consistently · 112faf44
      Nicolas Capens authored
      Each non-fallthrough case should end with a break (or return). If a
      scope is needed because local variables are defined, it should end
      before this break.
      
      This avoids bugs such as:
      
      switch(i)
      {
      case 0:
          if(c)
          {
              // lots
              // of
              // code
      
              // Easy to misread as always breaking instead of conditionally
              // falling through due to not spotting the if(c).
              break;
          }
      
      case 1:
          // ...
      }
      
      The new scope should also be indented. It makes it easier to spot where
      each case ends and where the switch ends. This is achieved by setting
      IndentCaseBlocks to true.
      
      Lastly, the case labels themselves should not be indented. Like goto
      labels they mark where in the code to jump to, and the code itself is
      already indented within the switch block.
      
      Bug: b/144825072
      Change-Id: I9a130d1d234795f53b5872e411f1315f56a0e908
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39551
      Commit-Queue: Nicolas Capens <nicolascapens@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
  9. 20 Apr, 2021 2 commits
  10. 16 Apr, 2021 1 commit
  11. 14 Apr, 2021 1 commit
  12. 13 Apr, 2021 2 commits
  13. 09 Apr, 2021 1 commit
  14. 29 Mar, 2021 1 commit
    • Automate installing the API library for testing · 4c0f888d
      Nicolas Capens authored
      To run dEQP tests we previously either had to install the Vulkan Loader
      and configure it to find the SwiftShader Vulkan ICD, or manually copy
      over the library.
      
      This change introduces the SWIFTSHADER_VULKAN_API_LIBRARY_INSTALL_PATH
      environment variable, which can be set to a path where the API library
      should be copied to. When used with dEQP it ensures we always test with
      the last build, instead of the path provided in the JSON file used by
      the Vulkan loader.
      
      Note this is only meant as a convenience for SwiftShader development.
      It shouldn't be used as a substitute for installing the ICD for
      system-wide usage. The latter should probably use CMAKE_INSTALL_PREFIX
      instead, but there are no known use cases yet for installing SwiftShader
      as the system-level driver, through the CMake build.
      
      Bug: b/149486511
      Change-Id: I5ec9d669967ba0c05a763263605ee0ad5cfd505e
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53768
      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 avatarAlexis Hétu <sugoi@google.com>
  15. 26 Mar, 2021 1 commit
  16. 25 Mar, 2021 2 commits
  17. 24 Mar, 2021 1 commit
  18. 17 Mar, 2021 1 commit
  19. 16 Mar, 2021 1 commit
    • Fix multiview renderpass queries · a0aeb64e
      Nicolas Capens authored
      The spec states that "If queries are used while executing a render pass
      instance that has multiview enabled, the query uses N consecutive query
      indices in the query pool (starting at query) where N is the number of
      bits set in the view mask in the subpass the query is used in. How the
      numerical results of the query are distributed among the queries is
      implementation-dependent. For example, some implementations may write
      each view’s results to a distinct query, while other implementations
      may write the total result to the first query and write zero to the
      other queries."
      
      This wasn't working properly for occlusion queries, but we missed it
      because dEQP doesn't provide coverage for this case if timestamp queries
      are not supported. This change fixes it for both query types.
      
      Note that for occlusion queries we write the total result to the first
      query, and set the remaining query results to 0, as explicitly allowed
      by the spec.
      
      For timestamp queries each query result is a valid timestamp (note that
      the spec also allows for only the first query to be a timestamp, while
      the remaining ones are zero).
      
      Bug: b/142643809
      Change-Id: I531248c2822c5f68d8636d4a3d153082c48cac1d
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53668
      Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
  20. 15 Mar, 2021 1 commit
  21. 13 Mar, 2021 1 commit
  22. 12 Mar, 2021 5 commits
  23. 11 Mar, 2021 2 commits
  24. 10 Mar, 2021 1 commit
  25. 08 Mar, 2021 1 commit