|author||Nicolas Capens <firstname.lastname@example.org>||Fri Feb 05 15:18:42 2021 -0500|
|committer||Nicolas Capens <email@example.com>||Fri Feb 19 21:06:06 2021 +0000|
Fix lowering and optimization of 64-bit absolute addresses x86-64 does not support 64-bit immediates as absolute memory addresses. They have to be stored in a register, which can then be used as [base]. Previously we addressed this at the SubzeroReactor level by emitting a Bitcast from an Ice::Operand to an Ice::Variable, for which Subzero already supported 64-bit constants as input. This change implements X86OperandMem creation from a 64-bit constant operand by letting legalize() move it into a GPR and using it as the memory operand's base register. A Reactor unit test is added to exercise this. Another issue was that doLoadOpt() assumed all load instructions are candidates for fusing into a subsequent instruction which takes the result of the load. This isn't true when for 64-bit constant addresses an instruction to copy it into a register is inserted. For now this case is simply skipped. A future optimization could adjust the iterators properly so the load from [base] can be fused with the next instruction. Lastly, it is possible for a 64-bit constant to fit within a 32-bit immediate, in which case legalize() by default does not perform the copy into a GPR (note this is to allow moves and calls with 64-bit immediates, where they are legal), and simply returns the 64-bit constant. So we must not allow legalization to an immediate in this case. Note that while we could replace it with a 32-bit constant, it's rare for absolute addresses to fit in this range, and it would be non-deterministic which path is taken, so for consistency we don't perform this optimization. Bug: b/148272103 Change-Id: I5fcfa971dc93f2307202ee11619e84c65fe46188 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52768 Tested-by: Nicolas Capens <firstname.lastname@example.org> Presubmit-Ready: Nicolas Capens <email@example.com> Reviewed-by: Antonio Maiorano <firstname.lastname@example.org>
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.
cd build cmake .. cmake --build . --parallel ./vk-unittests
Tip: Set the CMAKE_BUILD_PARALLEL_LEVEL environment variable to control the level of parallelism.
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
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
Some tests will automatically be run against the change. Notably, presubmit.sh verifies the change has been formatted using clang-format 10.0. Most IDEs come with clang-format support, but may require downgrading to clang-format version 10.0.
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:
llvm-subzero contains a minimized set of LLVM dependencies of the Subzero project.
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.
Public mailing list: email@example.com
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.