1. 09 Apr, 2021 1 commit
  2. 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>
  3. 26 Mar, 2021 1 commit
  4. 25 Mar, 2021 2 commits
  5. 24 Mar, 2021 1 commit
  6. 17 Mar, 2021 1 commit
  7. 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>
  8. 15 Mar, 2021 1 commit
  9. 13 Mar, 2021 1 commit
  10. 12 Mar, 2021 5 commits
  11. 11 Mar, 2021 2 commits
  12. 10 Mar, 2021 1 commit
  13. 08 Mar, 2021 2 commits
  14. 05 Mar, 2021 1 commit
  15. 04 Mar, 2021 1 commit
    • Implement VK_KHR_timeline_semaphore · 6846389f
      Sean Risser authored
      Timeline semaphores track a monotonically increasing uint64_t that
      serves as a signal to any number of threads on the device or the host.
      Threads and the host wait on the value of the payload to become a
      specific value, then unblock. Or they can signal the semaphore and
      update its value, unblocking all threads waiting on that value in the
      process.
      
      Clang's Thread Safety Analysis is not used for TimelineSemaphore as
      it has a bug that prevents it from properly analyzing lambdas that access
      guarded resources.
      
      Change-Id: Iafd95b8eac11beea21c00df87ca7ca1e51c77c64
      Bug: b/147738281
      Test: dEQP-VK.api.info.vulkan1p2_limits_validation.timeline_semaphore
      Test: dEQP-VK.synchronization.basic.timeline_semaphore.*
      Test: dEQP-VK.synchronization.timeline_semaphore.*
      Test: dEQP-VK.synchronization.op.single_queue.timeline_semaphore.*
      Test: dEQP-VK.synchronization.cross_instance.*
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52148
      Kokoro-Result: kokoro <noreply+kokoro@google.com>
      Tested-by: 's avatarSean Risser <srisser@google.com>
      Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>
      Commit-Queue: Sean Risser <srisser@google.com>
  16. 03 Mar, 2021 1 commit
  17. 26 Feb, 2021 2 commits
  18. 24 Feb, 2021 6 commits
  19. 22 Feb, 2021 4 commits
  20. 20 Feb, 2021 4 commits
  21. 19 Feb, 2021 1 commit
    • Fix lowering and optimization of 64-bit absolute addresses · bc1a66c7
      Nicolas Capens authored
      x86-64 does not support 64-bit immediates as absolute memory addresses.
      They have to be stored in a register, which can then be used as [base].
      
      Previously we addressed this at the SubzeroReactor level by emitting a
      Bitcast from an Ice::Operand to an Ice::Variable, for which Subzero
      already supported 64-bit constants as input.
      
      This change implements X86OperandMem creation from a 64-bit constant
      operand by letting legalize() move it into a GPR and using it as the
      memory operand's base register.
      
      A Reactor unit test is added to exercise this.
      
      Another issue was that doLoadOpt() assumed all load instructions are
      candidates for fusing into a subsequent instruction which takes the
      result of the load. This isn't true when for 64-bit constant addresses
      an instruction to copy it into a register is inserted.
      
      For now this case is simply skipped. A future optimization could adjust
      the iterators properly so the load from [base] can be fused with the
      next instruction.
      
      Lastly, it is possible for a 64-bit constant to fit within a 32-bit
      immediate, in which case legalize() by default does not perform the copy
      into a GPR (note this is to allow moves and calls with 64-bit
      immediates, where they are legal), and simply returns the 64-bit
      constant. So we must not allow legalization to an immediate in this
      case. Note that while we could replace it with a 32-bit constant, it's
      rare for absolute addresses to fit in this range, and it would be
      non-deterministic which path is taken, so for consistency we don't
      perform this optimization.
      
      Bug: b/148272103
      Change-Id: I5fcfa971dc93f2307202ee11619e84c65fe46188
      Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52768Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
      Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
      Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>