[Mesa-dev] Merge of glsl2 branch to master
keithw at vmware.com
Wed Aug 11 08:09:47 PDT 2010
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.
More information about the mesa-dev