Skip to content

S
swiftshader
Switch branch/tag
  1. 22 Feb, 2021 1 commit
    • Implement propagation of stores to loads in single basic blocks · 3ffbd62b
      Nicolas Capens authored 
      For loads following stores in the same basic block, replace their result
with the data that was stored.

It transforms the output of the StoresInMultipleBlocks test from:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 add         dword ptr [rsp],3
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 add         dword ptr [rsp],5
 jmp         b

Into:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
 jmp         b

While at first this might seem like a regression, note that
`add [rsp],3` performs both a load and a store. The optimization pass
eliminated two load operations from this test. The redundant stores will
be eliminated by a subsequent change.

Also adds a unit test for the case where store-to-load propagation
should not be performed due to an indirect store through a pointer
happening in between.

Bug: b/179668593
Change-Id: I6ca133ac4e77bbbc3efd517dff6e8dee6d2dc147
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52533
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>
  3. 20 Feb, 2021 4 commits
  5. 19 Feb, 2021 8 commits
  7. 18 Feb, 2021 7 commits
  9. 17 Feb, 2021 3 commits
  11. 16 Feb, 2021 5 commits
  13. 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>
  15. 10 Feb, 2021 6 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>
    • Rename InstIntrinsicCall to InstIntrinsic · 33a77f7f
      Nicolas Capens authored 
      It is no longer derived from InstCall, and doesn't take a Target
parameter which could be a symbol to a function which implements
the intrinsic.

Note one can still emit actual Call instructions if a function call
is needed. Since the previous change which removed the Target parameter
we can no longer decide between implementing an intrinsic as inline
instructions or a function call at the Subzero level, but we can still
do that at the Reactor level which has its own concept of intrinsics.

This change also removes mentions of intrinsics representing function
calls. It also removes code related to PNaCl-specific LLVM intrinsics,
including the ability to look up intrinsics by name. The addArg(),
getArg(), and getNumArgs() methods, adopted from InstCall (but no longer
inherited from it), are kept for now due to risk of replacing the ones
for InstCall objects, while the confusion caused by keeping the
function-related "arg" term is deemed low.

Bug: b/179497998
Change-Id: I293f039853abff6f5bebda1b714774205bdec846
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52608
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>
    • Eliminate the InstIntrinsicCall Target parameter · 99bbb14b
      Nicolas Capens authored 
      It is no longer used now that profiling support at the Subzero level
is eliminated.

This change adjusts all of the uses of getSrc() on intrinsics to obtain
the correct operand, but does not yet make simplifications based on
having them align with load/store instructions.

Bug: b/179497998
Change-Id: I93705eaa1b7626184f612ab3a9755048004e531f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52529
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 avatarAntonio Maiorano <amaiorano@google.com>
    • Eliminate Subzero profiling support · d4f27d7a
      Nicolas Capens authored 
      We're never used this functionality, and shouldn't have a need for it.
Profiling information can be collected at the Reactor level or using
a profiler like VTune.

This functionality was the only thing using the `Target` parameter of
`InstIntrinsicCall`, which get in the way for aligning the parameters of
load- and store-like intrinsics with regular `InstLoad` and `InstStore`.

Bug: b/179497998
Change-Id: I5a0ad5ee8e0101f0879a97a1ea01e3efc5bebbe4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52528
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 avatarAntonio Maiorano <amaiorano@google.com>
    • Regres: Remove GLES tests from CI test runs · 9677c6d2
      Nicolas Capens authored 
      The legacy OpenGL ES implementation is deprecated in favor of SwANGLE,
and we haven't touched the GLES code in many months. These CI tests
consume valuable time, and tend to be flaky due to exhausting the
number of X handles. We still have our 'daily' test runs to provide
detection of regressions, so they can be safely removed from the CI
test runs.

Note that this change can also be (temporarily) reverted as part of a
new change which could use CI testing of dEQP-GLES.

Bug: b/153322216
Change-Id: I52cd2b89c04c95de486d85118edef6460ba82925
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52532
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAntonio Maiorano <amaiorano@google.com>
  17. 09 Feb, 2021 4 commits