commit | 6f1260556b102395e25e9991ee377701b66abfb4 | [log] [tgz] |
---|---|---|
author | Nicolas Capens <capn@google.com> | Sun Jun 27 10:17:18 2021 -0700 |
committer | Nicolas Capens <nicolascapens@google.com> | Mon Jul 05 20:02:47 2021 +0000 |
tree | 044109e0944a1410470d8116fccc5d0fdef041f8 | |
parent | 07fd995bf80da968a7d4e2d9a7edfb14a458868d [diff] |
Fix -Wundefined-var-template warnings 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: Nicolas Capens <nicolascapens@google.com> Reviewed-by: Alexis Hétu <sugoi@google.com>
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.
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.
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.
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).
SwiftShader's OpenGL ES implementation can be tested using the dEQP test suite.
See docs/dEQP.md for details.
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.
See docs/Index.md.
Public mailing list: swiftshader@googlegroups.com
General bug tracker: https://g.co/swiftshaderbugs
Chrome specific bugs: https://bugs.chromium.org/p/swiftshader
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.
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.