Oded Gabbay
39b4dfe6ab
There are currently two methods in llvmpipe code to calculate coeffs to
be used as inputs for the fragment shader. The two methods use slightly
different ways to do the floating point calculations and thus produce
slightly different results.
The decision which method to use is determined by the size of the vector
that is used by the platform.
For vectors with size of more than 128bit, a single-step method is used,
in which coeffs_init_simple() + attribs_update_simple() are called.
For vectors with size of 128bit or less, a two-step method is used, in
which coeffs_init() + attribs_update() are called.
This causes some piglit tests (clip-distance-bulk-copy,
interface-vs-unnamed-to-fs-unnamed) to fail when using platforms with
128bit vectors (such as ppc64le or x86-64 without AVX).
This patch makes platforms with 128bit vectors use the single-step
method (aka "simple" method) instead of the two-step method.
This would make the resulting coeffs identical between more platforms,
make sure the piglit tests passes, and make debugging and maintainability
a bit easier as the generated LLVM IR will be the same for more platforms.
The performance impact is negligible for x86-64 without AVX, and
basically non-existent for ppc64le, as it can be seen from the following
benchmarking results:
- glxspheres, on ppc64le:
- original code: 4.892745317 frames/sec 5.460303857 Mpixels/sec
- with the patch: 4.932083873 frames/sec 5.504205571 Mpixels/sec
- Additional 0.8% performance boost
- glxspheres, on x86-64 without AVX:
- original code: 20.16418809 frames/sec 22.50323395 Mpixels/sec
- with the patch: 20.31328989 frames/sec 22.66963152 Mpixels/sec
- Additional 0.74% performance boost
- glmark2, on ppc64le:
- original code: score of 58
- with my change: score of 57
- glmark2, on x86-64 without AVX:
- original code: score of 175
- with the patch: score of 167
- Impact of of -4.5% on performance
- OpenArena, on ppc64le:
- original code: 3398 frames 1719.0 seconds 2.0 fps
255.0/505.9/2773.0/0.0 ms
- with the patch: 3398 frames 1690.4 seconds 2.0 fps
241.0/497.5/2563.0/0.2 ms
- 29 seconds faster with the patch, which is about 2%
- OpenArena, on x86-64 without AVX:
- original code: 3398 frames 239.6 seconds 14.2 fps
38.0/70.5/719.0/14.6 ms
- with the patch: 3398 frames 244.4 seconds 13.9 fps
38.0/71.9/697.0/14.3 ms
- 0.3 fps slower with the patch (about 2%)
Additional details can be found at:
http://lists.freedesktop.org/archives/mesa-dev/2015-October/098635.html
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
File: docs/README.WIN32 Last updated: 21 June 2013 Quick Start ----- ----- Windows drivers are build with SCons. Makefiles or Visual Studio projects are no longer shipped or supported. Run scons libgl-gdi to build gallium based GDI driver. This will work both with MSVS or Mingw. Windows Drivers ------- ------- At this time, only the gallium GDI driver is known to work. Source code also exists in the tree for other drivers in src/mesa/drivers/windows, but the status of this code is unknown. Recipe ------ Building on windows requires several open-source packages. These are steps that work as of this writing. - install python 2.7 - install scons (latest) - install mingw, flex, and bison - install pywin32 from here: http://www.lfd.uci.edu/~gohlke/pythonlibs get pywin32-218.4.win-amd64-py2.7.exe - install git - download mesa from git see http://www.mesa3d.org/repository.html - run scons General ------- After building, you can copy the above DLL files to a place in your PATH such as $SystemRoot/SYSTEM32. If you don't like putting things in a system directory, place them in the same directory as the executable(s). Be careful about accidentially overwriting files of the same name in the SYSTEM32 directory. The DLL files are built so that the external entry points use the stdcall calling convention. Static LIB files are not built. The LIB files that are built with are the linker import files associated with the DLL files. The si-glu sources are used to build the GLU libs. This was done mainly to get the better tessellator code. If you have a Windows-related build problem or question, please post to the mesa-dev or mesa-users list.