One of the pain points of working on compiler optimizations has been justifying them -- sometimes I come up with something I think is useful and spend a day or two on it, but the value doesn't show up as fps in the application that suggested the optimization to me. Then I wonder if this transformation of the code is paying off in general, and thus if I should push it. If I don't push it, I end up bringing that patch out on every application I look at that it could affect, to see if now I finally have justification to get it out of a private branch.
At a conference this week, we heard about how another team is are using a database of (assembly) shaders, which they run through their compiler and count resulting instructions for testing purposes. This sounded like a fun idea, so I threw one together. Patch #1 is good in general (hey, link errors, finally!), but also means that a quick hack to glslparsertest makes it link a passing compile shader and therefore generate assembly that gets dumped under INTEL_DEBUG=wm. Patch #2 I used for automatic scraping of shaders in every application I could find on my system at the time. The open-source ones I pushed to: http://cgit.freedesktop.org/~anholt/shader-db And finally, patch #3 is something I built before but couldn't really justify until now. However, given that it reduced fragment shader instructions 0.3% across 831 shaders (affecting 52 of them including yofrankie, warsow, norsetto, and gstreamer) and didn't increase instructions anywhere, I'm a lot happier now. Hopefully we hook up EXT_timer_query to apitrace soon so I can do more targeted optimizations and need this less :) In the meantime, I hope this can prove useful to others -- if you want to contribute appropriately-licensed shaders to the database so we track those, or if you want to make the analysis work on your hardware backend, feel free. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
