[Mesa-dev] Merge of glsl2 branch to master

[Keith Whitwell]

On Tue, 2010-08-10 at 12:43 -0700, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Keith Whitwell wrote:
> > On Mon, 2010-08-09 at 23:48 -0700, Eric Anholt wrote:
> >> The previous compiler called _mesa_remove_output_reads unconditionally,
> >> while the new compiler doesn't.  This should be left up to the backend
> >> in my opinion, so perhaps a little flag like Shader.EmitNoIfs and
> >> friends for r300g to set for now to call this for the Mesa IR generation
> >> would be a good solution.
> > 
> > It seems like this represents a change in the semantics of the mesa
> > driver interface -- previously mesa had the (perhaps implicit) rule that
> > OUT registers were write-only.  The glsl2 branch appears not to be
> > respecting that.
> > 
> > I don't really mind this as a follow-on change, but it seems like it
> > would be cleaner to keep the glsl2 merge as purely a change on one side
> > of the interface, not one which requires a change to drivers or the
> > interface itself.
> 
> I has always thought that ARB_vp/fp allowed this, but it seems that I
> was wrong.  I see two options two resolve this:
> 
> 1. Always generate duplicate writes to shadow copies of shader outputs.
>  Generate all reads from the shadow copies.  Rely on the optimizer to
> remove the dead writes.
> 
> 2. Add a lowering pass that inserts the shadow copies only for the
> shader outputs that are actually read.

> I'm leaning towards option #2 for a couple reasons.  I suspect that the
> optimizer may not eliminate some of the extra writes.  Option #2 also
> allows backends that don't need the shadow copies (i.e., i965) to skip
> the extra pass.
> 
> On the flip side, I think option #1 may be easier to implement.

I think either is fine - it really just boils down to satisfying the
constraint by whichever method is easiest.

> In either case, I've submitted a bug to track this issue.  Someone
> should hack up a validator for Mesa IR and TGSI (like the ir_validate
> pass).  I'm sure there other implicit, undocumented invariant
> assumptions sprinkled through the code.  Catching deviations from those
> sooner rather than later is the winning plan.

This has been on my list for a while, Corbin's galahad layer is an ideal
place for it to live.

Keith