Skip to content

S
swiftshader
Switch branch/tag
  1. 07 Jul, 2021 2 commits
    • Assume Microsoft ABI on Windows · 52cb3d1b
      Nicolas Capens authored 
      The SUBZERO_USE_MICROSOFT_ABI macro definition was used to indicate that
we want to use the Microsoft x86-64 calling convention, instead of
the System V one which PNaCl assumes (even on Windows). Using the
standard _WIN64 macro instead makes us not require defining the custom
one as part of our build.

SUBZERO_USE_MICROSOFT_ABI was also being used to decide whether to emit
stack probes. For 32-bit Windows targets, use the _WIN32 macro instead.
Note that when _WIN64 is defined, _WIN32 is also defined, but to avoid
confusion we use _WIN64 in the X8664 backend.

Bug: b/179832693
Change-Id: Ic2e62d3dc26543876673c07b9ccc01e9d92762bf
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/55528
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
    • Eliminate support for the PNaCl ABI · 97e0693e
      Nicolas Capens authored 
      PNaCl uses the ILP32 data model, even on x86-64 (cf. the x32 ABI).
Reactor instead always uses LP64 on 64-bit.

The main technical difference is the ILP32 on x86-64 used the address-
size override prefix (0x67) for every instruction that accesses
memory, which makes it look at only the lower 32-bit part of base and
index registers. Note this only works in a sandbox-like environment,
where memory is allocated in the lower 4 GiB range, such as PNaCl.

Bug: b/179832693
Change-Id: I068ddd12b1827e3babc49a06ddf26b932d2082c5
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/55468
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
  3. 06 Jul, 2021 5 commits
  5. 05 Jul, 2021 2 commits
    • Fix -Wundefined-var-template warnings · 6f126055
      Nicolas Capens authored 
      This warning, which we treat as an error, occurs when a static member of
an implicitly instatiated template class is referenced, but there is no
definition available in the current translation unit.

Note that with a non-template class this isn't a problem, since there
can only be one definition, which is expected to be resolved at link
time. But with a template class each instantiation can have a different
static member variable definition.

This warning typically occurs when the definition is available in
another translation unit, so it may be tempting to move that definition
into the header file to make it available to any translation unit where
the static member may be referenced. However, this typically leads to
multiple-definition errors.

Like all multiple-definition errors, we can address that by declaring,
not defining, the variable in the header, and leaving the definition in
one translation unit. In the case of a non-template class the
declaration in the class definition suffices since it's fully
instantiated, but for a template class we need to re-declare the static
member for the explicit instantiation.

Concretely, in this case Subzero has a template class for x86
instructions, with a static member for the Opcode string. This string is
different for each instantiation of the instruction template, so we need
to forward-declare each instantiated class's static member in the
header. There's already a macro for the definitions, which is repurposed
for declaring the instantiated members in the header.

Note that the C++ reference states that "An explicit specialization of a
static data member of a template is a definition if the declaration
includes an initializer; otherwise, it is a declaration."
(https://en.cppreference.com/w/cpp/language/template_specialization)
But Visual Studio treats them as definitions anyway, leading to
multiple-definition errors. Note that we can't add 'extern' to
explicitly make it a declaration only, because storage-class specifiers
are not valid for class members. So we just omit the declaration for
compilers other than Clang, which don't have this warning enabled
anyway.

Bug: chromium:604888
Change-Id: I63b58ecdf956ff264e6d25738684b513f05b268b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/55208
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarAlexis Hétu <sugoi@google.com>
    • Regres: Increase MaxProcMemory to 6 GiB · 07fd995b
      Nicolas Capens authored 
      Increasing the maxComputeWorkGroupInvocations to 256 revealed that we're
consuming a lot of memory with the Subzero JIT for compute shaders that
contain control barriers, due to implementing them with the use of
fibers which each have a 1 MiB stack.

Increasing Regres's maximum memory consumption per process keeps the
tests passing while we work on a more long-term solution.

Bug: b/192475710
Change-Id: I027d97d9f28d9749628fc008fe956fd436c77562
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/55368
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarCorentin Wallez <cwallez@google.com>
  7. 02 Jul, 2021 1 commit
  9. 01 Jul, 2021 2 commits
  11. 30 Jun, 2021 1 commit
  13. 29 Jun, 2021 3 commits
  15. 28 Jun, 2021 6 commits
  17. 25 Jun, 2021 3 commits
  19. 23 Jun, 2021 1 commit
  21. 21 Jun, 2021 1 commit
  23. 18 Jun, 2021 2 commits
  25. 17 Jun, 2021 2 commits
  27. 16 Jun, 2021 1 commit
  29. 15 Jun, 2021 1 commit
  31. 10 Jun, 2021 2 commits
  33. 08 Jun, 2021 1 commit
  35. 07 Jun, 2021 1 commit
  37. 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>