1FAQ 2=== 3 4Why another software rasterizer? 5-------------------------------- 6 7Good question, given there are already three (swrast, softpipe, 8llvmpipe) in the Mesa tree. Two important reasons for this: 9 10 * Architecture - given our focus on scientific visualization, our 11 workloads are much different than the typical game; we have heavy 12 vertex load and relatively simple shaders. In addition, the core 13 counts of machines we run on are much higher. These parameters led 14 to design decisions much different than llvmpipe. 15 16 * Historical - Intel had developed a high performance software 17 graphics stack for internal purposes. Later we adapted this 18 graphics stack for use in visualization and decided to move forward 19 with Mesa to provide a high quality API layer while at the same 20 time benefiting from the excellent performance the software 21 rasterizerizer gives us. 22 23What's the architecture? 24------------------------ 25 26SWR is a tile based immediate mode renderer with a sort-free threading 27model which is arranged as a ring of queues. Each entry in the ring 28represents a draw context that contains all of the draw state and work 29queues. An API thread sets up each draw context and worker threads 30will execute both the frontend (vertex/geometry processing) and 31backend (fragment) work as required. The ring allows for backend 32threads to pull work in order. Large draws are split into chunks to 33allow vertex processing to happen in parallel, with the backend work 34pickup preserving draw ordering. 35 36Our pipeline uses just-in-time compiled code for the fetch shader that 37does vertex attribute gathering and AOS to SOA conversions, the vertex 38shader and fragment shaders, streamout, and fragment blending. SWR 39core also supports geometry and compute shaders but we haven't exposed 40them through our driver yet. The fetch shader, streamout, and blend is 41built internally to swr core using LLVM directly, while for the vertex 42and pixel shaders we reuse bits of llvmpipe from 43``gallium/auxiliary/gallivm`` to build the kernels, which we wrap 44differently than llvmpipe's ``auxiliary/draw`` code. 45 46What's the performance? 47----------------------- 48 49For the types of high-geometry workloads we're interested in, we are 50significantly faster than llvmpipe. This is to be expected, as 51llvmpipe only threads the fragment processing and not the geometry 52frontend. The performance advantage over llvmpipe roughly scales 53linearly with the number of cores available. 54 55While our current performance is quite good, we know there is more 56potential in this architecture. When we switched from a prototype 57OpenGL driver to Mesa we regressed performance severely, some due to 58interface issues that need tuning, some differences in shader code 59generation, and some due to conformance and feature additions to the 60core swr. We are looking to recovering most of this performance back. 61 62What's the conformance? 63----------------------- 64 65The major applications we are targeting are all based on the 66Visualization Toolkit (VTK), and as such our development efforts have 67been focused on making sure these work as best as possible. Our 68current code passes vtk's rendering tests with their new "OpenGL2" 69(really OpenGL 3.2) backend at 99%. 70 71piglit testing shows a much lower pass rate, roughly 80% at the time 72of writing. Core SWR undergoes rigorous unit testing and we are quite 73confident in the rasterizer, and understand the areas where it 74currently has issues (example: line rendering is done with triangles, 75so doesn't match the strict line rendering rules). The majority of 76the piglit failures are errors in our driver layer interfacing Mesa 77and SWR. Fixing these issues is one of our major future development 78goals. 79 80Why are you open sourcing this? 81------------------------------- 82 83 * Our customers prefer open source, and allowing them to simply 84 download the Mesa source and enable our driver makes life much 85 easier for them. 86 87 * The internal gallium APIs are not stable, so we'd like our driver 88 to be visible for changes. 89 90 * It's easier to work with the Mesa community when the source we're 91 working with can be used as reference. 92 93What are your development plans? 94-------------------------------- 95 96 * Performance - see the performance section earlier for details. 97 98 * Conformance - see the conformance section earlier for details. 99 100 * Features - core SWR has a lot of functionality we have yet to 101 expose through our driver, such as MSAA, geometry shaders, compute 102 shaders, and tesselation. 103 104 * AVX512 support 105 106What is the licensing of the code? 107---------------------------------- 108 109 * All code is under the normal Mesa MIT license. 110 111Will this work on AMD? 112---------------------- 113 114 * If using an AMD processor with AVX or AVX2, it should work though 115 we don't have that hardware around to test. Patches if needed 116 would be welcome. 117 118Will this work on ARM, MIPS, POWER, <other non-x86 architecture>? 119------------------------------------------------------------------------- 120 121 * Not without a lot of work. We make extensive use of AVX and AVX2 122 intrinsics in our code and the in-tree JIT creation. It is not the 123 intention for this codebase to support non-x86 architectures. 124 125What hardware do I need? 126------------------------ 127 128 * Any x86 processor with at least AVX (introduced in the Intel 129 SandyBridge and AMD Bulldozer microarchitectures in 2011) will 130 work. 131 132 * You don't need a fire-breathing Xeon machine to work on SWR - we do 133 day-to-day development with laptops and desktop CPUs. 134 135Does one build work on both AVX and AVX2? 136----------------------------------------- 137 138Yes. The build system creates two shared libraries, ``libswrAVX.so`` and 139``libswrAVX2.so``, and ``swr_create_screen()`` loads the appropriate one at 140runtime. 141 142