Software backend

llvmpipe vs swiftshader current performance investigation

Possible next steps

• Try to figure out the per pixel shading times to compare between llvmpipe and swiftshader
• Fix correctness bugs in swiftshader
• Determine the performance difference between llvmpipe and basic
• Fix low hanging performance fruit when running on llvmpipe. i.e. I believe picture caching is still blitting tiles using draws and shaders instead of just using blits.

Architecture

llvmpipe and swiftshader both run the pixel shader on 2x2 blocks of pixels. A pixel is represented as something like Pixel{ a[f32; 4], r: [f32; 4], g: [f32; 4], b: [f32; 4]} or specifically Vector4f in SwiftShader. This way, all "a" for a block are placed in a SIMD word and processed together, same for "r"s, "g"s, and "b"s.

The vertex shader is similarly run on 4 vertices at a time.

Z buffer

Both llvmpipe and swiftshader seem to use a linear z buffer. i.e. no hierarchical-Z. This probably isn't so bad for llvmpipe because it does pixel shading a tile at a time and so we're more likely to hit the cache for subsequent draws. It does seem like it would be more of a problem for SwiftShader.

Custom

I'm experimenting with compiling the WebRender shaders to C++. We could potentially do this at build time which would avoid the need to ship a jit which is good for code size and security. (We can opt out of being able to make pages executable in the gpu process)

One challenge with this approach is that we'd want to know the sampler state at compile time.