On 01/09/2012 05:26 PM, Eric Anholt wrote:
On Fri, 6 Jan 2012 16:50:00 -0800, "Ian Romanick"<i...@freedesktop.org> wrote:
From: Ian Romanick<ian.d.roman...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
