|author||Nicolas Capens <email@example.com>||Fri Nov 08 16:29:24 2019 -0500|
|committer||Nicolas Capens <firstname.lastname@example.org>||Thu Nov 14 17:25:49 2019 +0000|
Rasterize 'Bresenham' line segments as parallelograms The previous 'connected diamonds' polygon that was used to rasterize Bresenham lines suffered from duplicate rasterization of endpoints, which violates the diamond exit-rule and is disallowed by the Vulkan (and OpenGL) spec. This change rasterizes Bresenham lines as a parallelogram, as described by Vulkan's non-strictLines algorithm. This satisfied Vulkan's requirements laid out in section 26.10.2 Bresenham Line Segment Rasterization: "Implementations may use other line segment rasterization algorithms, subject to the following rules: - The coordinates of a fragment produced by the algorithm must not deviate by more than one unit in either x or y framebuffer coordinates from a corresponding fragment produced by the diamond- exit rule. - The total number of fragments produced by the algorithm must not differ from that produced by the diamond-exit rule by no more than one. - For an x-major line, two fragments that lie in the same framebuffer- coordinate column must not be produced (for a y-major line, two fragments that lie in the same framebuffer-coordinate row must not be produced). - If two line segments share a common endpoint, and both segments are either x-major (both left-to-right or both right-to-left) or y-mayor (both bottom-to-top or both top-to-bottom), then rasterizing both segments must not produce duplicate fragments. Fragments also must not be omitted so as to interrupt continuity of the connected segments." OpenGL ES line rasterization has not been modified as part of this change, to not require rebasing of golden images, but the parallelogram algorithm was made available for easy comparison. Bug: b/80135519 Change-Id: I09e8b90a393d3a08387d79669d9dbe5f83a0811d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38049 Presubmit-Ready: Nicolas Capens <email@example.com> Kokoro-Presubmit: kokoro <firstname.lastname@example.org> Tested-by: Nicolas Capens <email@example.com> Reviewed-by: Chris Forbes <firstname.lastname@example.org> Reviewed-by: Alexis Hétu <email@example.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.
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.
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
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.
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: firstname.lastname@example.org
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.