Skip to content

S
swiftshader
Switch branch/tag
  1. 26 Mar, 2021 1 commit
  3. 25 Mar, 2021 2 commits
  5. 24 Mar, 2021 1 commit
  7. 17 Mar, 2021 1 commit
  9. 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>
  11. 15 Mar, 2021 1 commit
  13. 13 Mar, 2021 1 commit
  15. 12 Mar, 2021 5 commits
  17. 11 Mar, 2021 2 commits
  19. 10 Mar, 2021 1 commit
  21. 08 Mar, 2021 2 commits
  23. 05 Mar, 2021 1 commit
  25. 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>
  27. 03 Mar, 2021 1 commit
  29. 26 Feb, 2021 2 commits
  31. 24 Feb, 2021 6 commits
  33. 22 Feb, 2021 4 commits
  35. 20 Feb, 2021 4 commits
  37. 19 Feb, 2021 3 commits
    • 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>
    • Eliminate code randomization support from Subzero · 6649bd02
      Nicolas Capens authored 
      SwiftShader has no use for this since shader execution with robustness
features enabled can not access memory outside of the graphics
resources. For Chromium it also runs in the GPU process, which isolates
it from browser-wide and even tab renderer data and code, and also has
its own sandboxing.

If we ever do need randomization to prevent attacks, and project Bunker
doesn't provide the needed site isolation, it should be implemented
either at the Reactor level or as separate transformation passes where
possible.

While previously this feature was already disabled, there might have
been inadvertent randomization which could explain our test time
variability. It may also improve code generation performance a bit to
not have this code around any more.

Bug: b/179832693
Change-Id: If1ccb54981edb61f443dd5949c56b75bab07c7c2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52808
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>
    • Fix Win32SurfaceKHR::getSurfaceCapabilities asserting when hwnd is no longer valid · 0540e683
      Antonio Maiorano authored 
      When vkGetPhysicalDeviceSurfaceCapabilitiesKHR is called, we now return
VK_ERROR_SURFACE_LOST_KHR on Windows if the window handle (hwnd) is no
longer valid.

The assert was being tripped by Chromium's compositor_unittests for test
LayerWithRealCompositorTest.BackgroundBlur. With this fix, instead of an
assert, the test now fails because eglQuerySurface fails with
EGL_BAD_SURFACE.

Bug: chromium:1174372
Change-Id: I71164c30bddaa41753472389e996cebbff7fbf77
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52928Tested-by: 's avatarAntonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>