SPIR-V is a simple binary intermediate language used for graphics shaders and compute kernels. Wearing my work hat (I work at Codeplay Software Ltd.) I have been contributing to the SPIR-V specification since 2014 as one of the authors. SPIR-V’s primary goals are (as according to me): Have a regular binary structure. Be easily extendable. Be easy to validate for correctness. Be easy to produce from compiler toolchains. Be easy to consume in tools and drivers.

In a previous post I introduced a little command line tool spirv-stats I’ve been working on. Since doing the initial version, I’ve extended the information the tool will give you based on some queries I had on the SPIR-V binaries we were using - in the GitHub pull request here. For the most commonly used opcodes, I’ve tried to break them down to understand a little more about the shape of the opcodes.

I’ve just released a small one C++ file tool called spirv-stats. It will take one or more SPIR-V input files, and calculate the composition of the SPIR-V shader modules like so: It firstly outputs the total number of hits in the SPIR-V shader module(s) - this is the total number of opcodes found within the module(s). Then it outputs the total byte size of the module(s), followed by a sorted breakdown of the module(s), with the most hit opcodes coming first.

In my previous post cleaning up the parser, I had rationalised the parser for my custom language I’m calling Neil - Not Exactly an Intermediate Language. The next step in making my language more useful and expression is to add the ability to arbitrarily create variables within a function, store an initial value to the variable, and then be able to update the variable. Previously, our language could handle: Whereas now we want it to be able to handle:

I was recently made aware of the awesome JSON parser/writer benchmark suite nativejson-benchmark (thanks to the awesome @chadaustin). The suite takes over 40 different JSON libraries and compares how fast the can parse/write JSON, but also has a set of test cases that cover some really obtuse corner cases that a lot of parsers missed. One of the parsers that failed some of these tests was my own one json.h, so in pull request #42 I’ve merged in the fixes for the failures uncovered by the test suite.