[Mesa-dev] [PATCH 09/14] i965: Remove brw_fs_precompile

[Kenneth Graunke]

On 01/09/2012 05:26 PM, Eric Anholt wrote:
> On Fri,  6 Jan 2012 16:50:00 -0800, "Ian Romanick"<idr at freedesktop.org>  wrote:
>> From: Ian Romanick<ian.d.romanick at intel.com>
>>
>> There are several things that could cause the fragment shader
>> precompile to fail.  Looking for calls to 'fail' in brw_fs_visitor.cpp
>> finds three classes of things:
>>
>>    * Trying to emit instructions that are invalid in 16-wide mode.
>>
>>    * Trying to emit instructions that should have been lowered.
>>
>>    * Register allocation failures.
>
> I'm really sad to see this code go.  It's been incredibly useful for
> tracking regressions in our code generation quality -- we have no other
> current tool for doing so, since doing actual measurement requires
> testing infrastructure we don't have.
>
> Apitracing single frames of apps would get us close to this, but it will
> miss shaders not involved in the frame you choose, the disk space cost
> is still stunning, redistribution of a collection of traces is even more
> difficult to accomplish while respecting copyright than shader-db, and
> we don't have any current collection of traces at all.
>
> If there's any way to retain this code, I'd like to.

Yeah...unfortunately, I agree with Eric on this one.  Ian, how hard 
would it be to keep it?  You could still remove the ability to raise 
link errors, as shader-db doesn't need that.

I am definitely no fan of the precompile in normal circumstances, but 
shader-db is immensely valuable when working on codegen optimizations, 
and without an up-front compile, I'm not sure how to make it happen.

Eric, how hard would it be to write a tool that, given a bunch of shader 
programs, compiled them, left all the non-orthogonal state at defaults, 
and did some dummy draw using the shaders so they actually get compiled 
all the way to assembly?  I'd estimate it as a day or two of work, but 
I'm probably missing something.  Then you wouldn't need this, and 
shader-db could still work.

An "apitrace dump-shaders" command that scraped GLSL and ARB programs 
from an app without actually writing a trace (for disk sake) would be 
useful as well.  Scraping from a trace would be nice, too.