PowerVR has captured my Imagination

Disclaimer:  The views expressed in this post are my own personal opinions and are not shared, sanctioned, or endorsed by anybody in particular (especially my employer).   Pyramid ShaderAnalyzer is a personal, non-profit endeavor, of which my employer has neither knowledge nor involvement.

You may have seen my pet project: Pyramid.

It all started when I decided I really wanted to have a GUI around AMD CodeXL, but after developing it, I had the idea that I could turn it into a one-stop shop for static shader analysis. My goal has been to glue together as many different shader analysis tools as possible into one convenient package. My other goal has been to pester encourage hardware vendors to be more open about their instruction sets, so that I can use the knowledge to produce faster pixels.

Yesterday was an exciting day, because Imagination Technologies released a new PowerVR SDK containing disassembling compilers and ISA documentation.  Naturally, I had to duct-tape integrate their compilers into my little tool.  You can get the new version of Pyramid here.  Although, if you want a more pleasant and PVR-centric experience, you may want to try PVRShaderEditor, which has syntax highlighting and line-by-line cycle counts.

To my new friends at Imagination, thank you for being open with your instruction set. Thank you for taking the time to enrich and empower the dev community. I hope that your example will inspire the rest of the IHVs to follow suit.  You want us scrutinizing your microcode. You want us knowing how it works so it’s in our minds while we’re designing our shaders.  You have nothing to lose and a lot of performance and mindshare to gain.

I’m looking at YOU Intel, Nvidia, Arm, and Qualcomm!  Who wants to be next?  Let’s collaborate guys.  I will work with you to get your disassemblers into my tool.  All I need is a stable interface that turns text into instructions.  I know that you have compilers. I know that these compilers, like all compilers, possess all sorts of interesting debug outputs. I know the code is there, floating around your source tree, surrounded by #ifdefs and caveats and unwritten rules.  Your engineers probably use it quite heavily.  It probably doesn’t change all that often.  All I need is for you to formalize it just a tiny bit, and then make it accessible.  It doesn’t have to be pretty.  I will roll up my sleeves if I have to, as long as my work isn’t invalidated by some future driver release.