commit | 157ba260ea72ad11ae439521391f4057353fed8c | [log] [tgz] |
---|---|---|
author | Nicolas Capens <capn@google.com> | Tue Dec 10 17:49:14 2019 -0500 |
committer | Nicolas Capens <nicolascapens@google.com> | Wed Dec 11 12:22:08 2019 +0000 |
tree | 03f5e9edc7eb94b6e25732cff08f43a0eb3f4e92 | |
parent | 72c398f5632fbefa1e4f32468cc0a1074276c088 [diff] |
Do not indent C++ namespace contents This is a style change. Visual Studio defaults to indenting namespace contents, and this was adopted for a long time, but with the new Vulkan implementation this was abandoned. However the legacy code borrowed from the OpenGL ES implementation still used indentation so it was inconsistent. The justification for not indenting namespace contents is that namespaces are merely a way to avoid name clashes with other projects we don't control directly (and in rare cases internal subprojects when we want to reuse the same names). Hence the vast majority of files have a single namespace, and unlike indentation used for ease of discerning control flow blocks, class contents, or function contents, which can become highly nested, there is no such readability advantage to indenting namespace contents. This is also the Google style recommendation (though no justification or discussion is provided): https://google.github.io/styleguide/cppguide.html#Namespace_Formatting One reasonable counter-argument is consistency with other blocks of curly brackets, but considering that most namespaces span almost the entire file, it's a substantial waste of line length. Because there is no indentation, there's also no need to have the open and closing brackets line up as a visual aid, like we prefer for other uses of curly brackets. So we place the open bracket on the same line as the namespace keyword. A comment is added to the closing bracket to discern it from other closing brackets. It also makes it easier to find the end of anonymous namespaces which typically go at the top of the source file. This change is make separately from applying clang-format because diff tools mark all these unindented lines as changes and this makes it hard to review the smaller style changes made by clang-format. The OpenGL ES and Direct3D code is left untouched because it is in maintenance mode and in case of regressions we want easy 'blame' tool usage. Bug: b/144825072 Change-Id: Ie2925ebd697e1ffa7c4cbdc9a946531f11f4d934 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39348 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Reviewed-by: Ben Clayton <bclayton@google.com> Tested-by: Nicolas Capens <nicolascapens@google.com>
SwiftShader is a high-performance CPU-based implementation of the Vulkan, OpenGL ES, and Direct3D 9 graphics APIs12. Its goal is to provide hardware independence for advanced 3D graphics.
SwiftShader libraries can be built for Windows, Linux, and Mac OS X.
Android and Chrome (OS) build environments are also supported.
Visual Studio
For building 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.
There is also a legacy SwiftShader.sln file for Visual Studio 2017 for building OpenGL ES and Direct3D libraries. Output DLLs will be placed in the out subfolder. Sample executables such as OGLES3ColourGrading can be found under the Tests solution folder and can be run from the IDE.
CMake
Install CMake for Linux, Mac OS X, or Windows and use either the IDE or run the following terminal commands:
cd build cmake .. make --jobs=8 ./gles-unittests ./OGLES2HelloAPI
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.
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
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 is part of Google Chrome‘s (Portable) Native Client project. Its authoritative source is at https://chromium.googlesource.com/native_client/pnacl-subzero/. The fork was made using git-subtree to include all of Subzero’s history, and until further notice it should not diverge from the upstream project. Contributions must be tested using the README instructions, reviewed at https://chromium-review.googlesource.com, and then pulled into the SwiftShader repository.
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.