The last time I wrote about Kraid, the new compiler we're writing for the Panfrost driver stack, the big news was that it was finally passing a single Vulkan CTS test. Today, the big news is that it's now passing all 800,000 of them, including a few the old compiler fails. Kraid is now a real compiler.

Before you get too excited, though, we're still far from done. The 100% pass rate is with only compute shaders going through Kraid. Vertex and fragment shading are still works in progress. We'll hopefully have those working in the next few weeks but they aren't implemented yet. Also, the quality of the generated code is still fairly poor. This isn't a problem with the design of Kraid, but rather it was a strategic choice. Having the register allocator make bad allocation decisions helps us ferret out bugs in the rest of the compiler that can occur when the register pressure gets tight and the allocator isn't able to make good decisions.

Importantly, however, we now have all the tools in place to make it good. Nearly every single item on our checklist of requirements for the new compiler has been checked off. Kraid now has:

• An SSA-based register allocator that's capable of allocating within an arbitrary fixed budget

• An SSA-based spiller that runs in near-linear time and always succeeds at getting the program to fit in the desired number of registers

• Proper handling of 64-bit operations

• Proper handling of integer and float widen operations on sources

• Full and correct swizzle support everywhere

• A copy-propagation pass capable of propagating both at the word and byte granularity, including seeing through swizzles and vector collect operations

• Full support for 16-bit destinations and seamlessly emulated support for 8-bit destinations. (Most instructions don't support actual 8-bit destinations, so we have to fake it by giving them 16 bits.)

• The encoding and any metadata about instructions is extracted directly from XML provided by Arm

• Hardware unit tests for most instructions which validate our understanding of the instruction's precise semantics against hardware

Where do we go from here?

Now that we've built the compiler, it's time to make it sing. We have all the core pieces in place. It's now time to shift gears and start looking at the code it generates and using the tools we've built to try and do better. There are still a few optimization passes that need to be written, the register allocator needs a lot of fine-tuning, and we need to refine our strategies around booleans and 8-bit data.

We also need to finish off the other two shader stages. Vertex shaders are pretty straightforward but fragment shaders are a bit trickier. The BLEND and ATEST instructions have register allocation implications, and the blend shaders themselves require us to define an ABI between the main fragment shader and the blend shader because BLEND sometimes ends up being a function pointer call. This ends up adding a bunch of subtle corners to the IR which we have yet to sort out. None of it is especially fundamental but there is some design work left to do.

Hopefully, we'll start to see some good performance improvements soon. Kraid is already better than the old compiler at 64-bit arithmetic. As we continue to make improvements, it will hopefully match or beat the old compiler for most workloads but that has yet to be seen.