1. 21 Jun, 2021 1 commit
  2. 18 Jun, 2021 2 commits
  3. 17 Jun, 2021 2 commits
  4. 16 Jun, 2021 1 commit
  5. 15 Jun, 2021 1 commit
  6. 10 Jun, 2021 2 commits
  7. 08 Jun, 2021 1 commit
  8. 07 Jun, 2021 1 commit
  9. 03 Jun, 2021 3 commits
    • Remove git submodules before rolling into Android · efe254de
      Nicolas Capens authored
      This change adds a script which is to be called by the SwiftShader into
      Android AutoRoller: https://autoroll.skia.org/r/swiftshader-android
      
      It prepares a checkout for upload into the Android repo. Specifically,
      Android does not allow remote submodules, so this script removes them.
      Note SwiftShader does not require any submodules to build the library;
      they are optional for development purposes.
      
      Bug: b/189557997
      Change-Id: I36b4ae59cd843f1c69146f0f52ce8f323c6bc15a
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/54768Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
    • Value-initialize all vk::GraphicsState members · 940f2acc
      Nicolas Capens authored
      The vk::GraphicsState constructor does not initialize all members in all
      code paths. We were relying on the zero-initializing done by
      vk::allocate() which is used to allocate vk::GraphicsPipeline which in
      turn contains a GraphicsState member.
      
      We want to change vk::allocate() to no longer zero-initialize all
      memory, to catch more MemorySanitizer errors made by applications. Thus
      we must also not rely on such automatic initialization ourselves.
      
      Note that this change might also hide MemorySantizer violations
      committed by the application side. For example some state is only copied
      from VkGraphicsPipelineCreateInfo into vk::GraphicsState on construction
      when flags indicate they're not dynamic state. If the application
      forgets to makerecord commands that set the dynamic state, their value
      is undefined:
      
      Vulkan 1.2.178 section 6. Command Buffers:
      "When a command buffer begins recording, all state in that command
      buffer is undefined."
      
      Vulkan 1.2.178 section 10.11. Dynamic State:
      "If the state is specified as dynamic in the new pipeline object, then
      that command buffer state is not disturbed. Before any draw or dispatch
      call with this pipeline there must have been at least one call to each
      of the corresponding dynamic state setting commands since the command
      buffer recording was begun, or the last bound pipeline object with that
      state specified as static, whichever was the latter."
      
      Thus once sw::allocate() no longer also zeroes this data, we should
      revert the value-initialization where possible and ensure we don't
      touch the uninitialized data ourselves, unless as a consequence of an
      application bug.
      
      Bug: b/140991626
      Change-Id: I060e8d8a79e93b0676669eed361fab4f86ab1b56
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53089
      Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
    • Explicitly initialize VkSpecializationInfo fields · 491ade49
      Nicolas Capens authored
      vk::allocate() zero-initializes its memory, which was nulling the
      VkSpecializationInfo::pMapEntries field in case the mapEntryCount is 0.
      
      We'll be changing vk::allocate() to not zero-initialize, to catch cases
      where applications might incorrectly be relying on it, with
      MemorySanitizer. So we have to also not be relying on it.
      
      Bug: b/140991626
      Change-Id: I5917c902c0af27985556340dfc1dbae79010a125
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/54468
      Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
  10. 02 Jun, 2021 2 commits
  11. 31 May, 2021 1 commit
  12. 29 May, 2021 2 commits
  13. 27 May, 2021 4 commits
  14. 26 May, 2021 1 commit
  15. 22 May, 2021 1 commit
  16. 21 May, 2021 3 commits
  17. 20 May, 2021 1 commit
  18. 19 May, 2021 3 commits
  19. 17 May, 2021 1 commit
  20. 14 May, 2021 2 commits
  21. 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>
  22. 11 May, 2021 1 commit
  23. 10 May, 2021 2 commits