On Tue, Mar 29, 2011 at 02:16:39PM -0700, Eric Anholt wrote:
> t
> On Tue, 29 Mar 2011 11:35:33 -0700, Tom Stellard <tstel...@gmail.com> wrote:
> > On Tue, Mar 29, 2011 at 10:19:13AM -0700, Eric Anholt wrote:
> > > On Mon, 28 Mar 2011 22:59:31 -0700, Tom Stellard <tstel...@gmail.com>
> > > wrote:
> > > > This pass scans programs for instructions that read registers that have
> > > > not been written and replaces these reads with a read from a constant
> > > > register with the value of zero. This pass prevents phantom
> > > > dependencies from being introduced by the register allocator and
> > > > improves the efficiency of subsequent optimization passes.
> > >
> > > I'm not sure why optimizing a program with undefined behavior (using
> > > undefined register values) is interesting. It just seems like an
> > > opportunity to make a mistake and break programs that should have
> > > defined behavior.
> >
> > The main problem I am trying to fix with this is that these reads
> > from undefined register values are causing the Mesa IR register allocator
> > to alter the structure of the program by adding dependencies between
> > instructions that should not be there. This is limiting the number of
> > optimization opportunities that are available to drivers, especially
> > on architectures like r300 that need IFs lowered and thus use a lot of
> > CMP instructions.
>
> Why do you have programs reading undefined values? Why are these
> programs interesting?
The reason there are reads of undefined values is because of all the
conditional assignments generated by the IF to conditional assignment
lowering pass. ir_to_mesa transforms conditional assignments to
CMP DST, COND SRC0 DST, with the assumption that if the condition fails
assigning DST to itself will be a noop. This is normally a safe assumption
to make since all bug-free programs should initialize a value before using
it in a conditional assignment, if the value is going to be used later
in the program.
However, the conditional assignments that are generated by the IF
lowering pass don't follow this pattern and the DST register is usually
uninitialized when the instruction is executed, leading to a read from
an undefined value.
It seems like the real problem is that there is no good way to translate
a GLSL IR conditional assignment to a MESA IR instruction. From what
I can tell, the semantics of conditional assignment are:
if (cond)
assign value
else
do nothing;
and the closest equivalent Mesa IR instruction (CMP) is:
if (cond)
assign value0
else
assign value1
Since this is only an issue on architectures that don't support flow
control, I should modify my patch so the 'reads without writes' pass
only runs on architectures that don't support flow control. I'm also
interested in hearing alternate solutions if anyone has other ideas,
because I would really like to get this fixed.
-Tom Stellard
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
