1 FAQ 2 === 3 4 Why another software rasterizer? 5 -------------------------------- 6 7 Good question, given there are already three (swrast, softpipe, 8 llvmpipe) 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 23 What's the architecture? 24 ------------------------ 25 26 SWR is a tile based immediate mode renderer with a sort-free threading 27 model which is arranged as a ring of queues. Each entry in the ring 28 represents a draw context that contains all of the draw state and work 29 queues. An API thread sets up each draw context and worker threads 30 will execute both the frontend (vertex/geometry processing) and 31 backend (fragment) work as required. The ring allows for backend 32 threads to pull work in order. Large draws are split into chunks to 33 allow vertex processing to happen in parallel, with the backend work 34 pickup preserving draw ordering. 35 36 Our pipeline uses just-in-time compiled code for the fetch shader that 37 does vertex attribute gathering and AOS to SOA conversions, the vertex 38 shader and fragment shaders, streamout, and fragment blending. SWR 39 core also supports geometry and compute shaders but we haven't exposed 40 them through our driver yet. The fetch shader, streamout, and blend is 41 built internally to swr core using LLVM directly, while for the vertex 42 and pixel shaders we reuse bits of llvmpipe from 43 ``gallium/auxiliary/gallivm`` to build the kernels, which we wrap 44 differently than llvmpipe's ``auxiliary/draw`` code. 45 46 What's the performance? 47 ----------------------- 48 49 For the types of high-geometry workloads we're interested in, we are 50 significantly faster than llvmpipe. This is to be expected, as 51 llvmpipe only threads the fragment processing and not the geometry 52 frontend. The performance advantage over llvmpipe roughly scales 53 linearly with the number of cores available. 54 55 While our current performance is quite good, we know there is more 56 potential in this architecture. When we switched from a prototype 57 OpenGL driver to Mesa we regressed performance severely, some due to 58 interface issues that need tuning, some differences in shader code 59 generation, and some due to conformance and feature additions to the 60 core swr. We are looking to recovering most of this performance back. 61 62 What's the conformance? 63 ----------------------- 64 65 The major applications we are targeting are all based on the 66 Visualization Toolkit (VTK), and as such our development efforts have 67 been focused on making sure these work as best as possible. Our 68 current code passes vtk's rendering tests with their new "OpenGL2" 69 (really OpenGL 3.2) backend at 99%. 70 71 piglit testing shows a much lower pass rate, roughly 80% at the time 72 of writing. Core SWR undergoes rigorous unit testing and we are quite 73 confident in the rasterizer, and understand the areas where it 74 currently has issues (example: line rendering is done with triangles, 75 so doesn't match the strict line rendering rules). The majority of 76 the piglit failures are errors in our driver layer interfacing Mesa 77 and SWR. Fixing these issues is one of our major future development 78 goals. 79 80 Why 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 93 What 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 106 What is the licensing of the code? 107 ---------------------------------- 108 109 * All code is under the normal Mesa MIT license. 110 111 Will 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 118 Will 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 125 What 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 135 Does one build work on both AVX and AVX2? 136 ----------------------------------------- 137 138 Yes. The build system creates two shared libraries, ``libswrAVX.so`` and 139 ``libswrAVX2.so``, and ``swr_create_screen()`` loads the appropriate one at 140 runtime. 141 142
