Value-initialize all vk::GraphicsState members

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: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
1 file changed
tree: 01c919e67c5497172df84f05df02d2e967b0f6bc
  1. .vscode/
  2. build/
  3. build_overrides/
  4. docs/
  5. extensions/
  6. include/
  7. infra/
  8. src/
  9. tests/
  10. third_party/
  11. tools/
  12. .clang-format
  13. .dir-locals.el
  14. .gitignore
  15. .gitmodules
  16. Android.bp
  17. AUTHORS.txt
  18. BUILD.gn
  19. CMakeLists.txt
  20. CMakeSettings.json
  21. codereview.settings
  22. CONTRIBUTING.txt
  23. CONTRIBUTORS.txt
  24. DIR_METADATA
  25. LICENSE.txt
  26. OWNERS
  27. README.md
README.md

SwiftShader

License

Introduction

SwiftShader is a high-performance CPU-based implementation of the Vulkan graphics API12. Its goal is to provide hardware independence for advanced 3D graphics.

NOTE: SwiftShader's OpenGL ES frontend is no longer supported, and will eventually be removed. Read more about our recommendation to use ANGLE on top of SwiftShader Vulkan here.

Building

SwiftShader libraries can be built for Windows, Linux, and macOS.
Android and Chrome (OS) build environments are also supported.

  • CMake
    Install CMake for Linux, macOS, or Windows and use either the GUI or run the following terminal commands:

    cd build
    cmake ..
    cmake --build . --parallel
    
    ./vk-unittests
    

    Tip: Set the CMAKE_BUILD_PARALLEL_LEVEL environment variable to control the level of parallelism.

  • Visual Studio
    To build the Vulkan ICD library, use Visual Studio 2019 to open the project folder and wait for it to run CMake. Open the CMake Targets View in the Solution Explorer and select the vk_swiftshader project to build it.

Usage

The SwiftShader libraries act as drop-in replacements for graphics drivers.

On Windows, most applications can be made to use SwiftShader's DLLs by placing them in the same folder as the executable. On Linux, the LD_LIBRARY_PATH environment variable or -rpath linker option can be used to direct applications to search for shared libraries in the indicated directory first.

In general, Vulkan applications look for a shared library named vulkan-1.dll on Windows (vulkan-1.so on Linux). This ‘loader’ library then redirects API calls to the actual Installable Client Driver (ICD). SwiftShader's ICD is named libvk_swiftshader.dll, but it can be renamed to vulkan-1.dll to be loaded directly by the application. Alternatively, you can set the VK_ICD_FILENAMES environment variable to the path to vk_swiftshader_icd.json file that is generated under the build directory (e.g. .\SwiftShader\build\Windows\vk_swiftshader_icd.json). To learn more about how Vulkan loading works, read the official documentation here.

Contributing

See CONTRIBUTING.txt for important contributing requirements.

The canonical repository for SwiftShader is hosted at: https://swiftshader.googlesource.com/SwiftShader

All changes must be reviewed and approved in the Gerrit review tool at: https://swiftshader-review.googlesource.com

Authenticate your account here: https://swiftshader-review.googlesource.com/new-password

All changes require a Change-ID tag in the commit message. A commit hook may be used to add this tag automatically, and can be found at: https://gerrit-review.googlesource.com/tools/hooks/commit-msg. To clone the repository and install the commit hook in one go:

git clone https://swiftshader.googlesource.com/SwiftShader && (cd SwiftShader && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)

Changes are uploaded to Gerrit by executing:

git push origin HEAD:refs/for/master

When ready, add a project owner as a reviewer on your change.

Some tests will automatically be run against the change. Notably, presubmit.sh verifies the change has been formatted using clang-format 11.0.1. Most IDEs come with clang-format support, but may require upgrading/downgrading to the clang-format version 11.0.0 release version (notably Chromium's buildtools has a clang-format binary which can be an in-between revision which produces different formatting results).

Testing

SwiftShader's OpenGL ES implementation can be tested using the dEQP test suite.

See docs/dEQP.md for details.

Third-Party Dependencies

The third_party directory contains projects which originated outside of SwiftShader:

subzero contains a fork of the Subzero project. It originates from Google Chrome‘s (Portable) Native Client project. The fork was made using git-subtree to include all of Subzero’s history.

llvm-subzero contains a minimized set of LLVM dependencies of the Subzero project.

PowerVR_SDK contains a subset of the PowerVR Graphics Native SDK for running several sample applications.

googletest contains the Google Test project, as a Git submodule. It is used for running unit tests for Chromium, and Reactor unit tests. Run git submodule update --init to obtain/update the code. Any contributions should be made upstream.

Documentation

See docs/Index.md.

Contact

Public mailing list: swiftshader@googlegroups.com

General bug tracker: https://g.co/swiftshaderbugs
Chrome specific bugs: https://bugs.chromium.org/p/swiftshader

License

The SwiftShader project is licensed under the Apache License Version 2.0. You can find a copy of it in LICENSE.txt.

Files in the third_party folder are subject to their respective license.

Authors and Contributors

The legal authors for copyright purposes are listed in AUTHORS.txt.

CONTRIBUTORS.txt contains a list of names of individuals who have contributed to SwiftShader. If you‘re not on the list, but you’ve signed the Google CLA and have contributed more than a formatting change, feel free to request to be added.

Disclaimer

  1. Trademarks are the property of their respective owners.
  2. This is not an official Google product.