[Mesa-dev] Merge of glsl2 branch to master

[Tom Stellard]

On Mon, Aug 09, 2010 at 07:05:52PM -0700, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Tom Stellard wrote:
> > On Fri, Aug 06, 2010 at 03:24:50PM -0700, Ian Romanick wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> As of today the glsl2 branch has three piglit regressions WRT master,
> >> and there is only one crashing piglit tests.  As before, we have tested
> >> swrast and i965.  For master I used commit 27041d7cb, and for glsl2 I
> >> used commit c234d0b2.  The results are available at
> >> http://people.freedesktop.org/~idr/results/.  The regressed tests cases are:
> >>
> >>  * draw_buffers-05.vert - As mentioned previously, the spec is ambiguous
> >> and Nvidia and AMD produce different results for this test.  Until the
> >> spec ambiguity is resolved, I don't care about this failure.
> >>
> >> * glsl1-texcoord varying - This test accesses gl_TexCoord[] using a
> >> non-constant index without dimensioning the array. The new compiler
> >> correctly rejects this shader. Nvidia accepts it, but I believe they're
> >> going outside the spec (which they do a lot). I haven't tested this on
> >> AMD or Apple yet. Is this shader from an application?  We've changed the
> >> test in piglit commit c6146f121, but I think it still isn't quite right.
> >>
> >>  * fbo-drawbuffers-maxtargets - Fails on i965 because we don' have loop
> >> unrolling in the compiler or good array handling in the driver.  We'll
> >> get loop unolling in the compiler first.  Proper array handling will
> >> come to the driver once we move away from using Mesa IR.
> >>
> >>
> >> I propose that we merge master to glsl2 on *Friday, August 13th* (one
> >> week from today).  Barring unforeseen issues, I propose that we merge
> >> glsl2 to master on *Monday, August 16th*.
> > 
> > Here is a summary of the piglit regressions on r300g (with an r500 card)
> 
> Thanks for the reply!  I was starting to wonder if my message went to
> /dev/null. :)
> 
> > These fail because r300 does not implement the SSG opcode:
> > glsl1-acos(vec4) function
> > glsl1-asin(vec4) function
> > glsl1-atan(vec4) function
> > glsl-fs-asin
> > glsl-fs-atan-1
> > glsl-fs-sign
> > glsl-vs-sign
> 
> "Set sign".  It's in NV_vertex_program2 (and 3) and NV_gpu_program4.
> 
> * SSG:  Adds a new "set sign" operation, which produces a vector holding
>   negative one for negative components, zero for components with a value
>   of zero, and positive one for positive components.  Equivalent results
>   could be achieved (less efficiently) in NV_vertex_program with
>   multiple SLT, SGE, and arithmetic instructions.
> 
> We can either add a lowering pass to break ir_unop_sign into more
> primitive operations, or drivers can implement the opcode.  I don't have
> a strong opinion here.
> 
> > This one fails because r300 does not implement the DP2 opcode:
> > glsl-fs-dot-vec2
> 
> Can r300 do a DP2?  I looked at the i915 documentation, and we can
> implement it there using a DP2A.  We can't do a lowering pass for this
> one, but we could have a flag to cause a different sequence to be
> generated.  In that case, it may actually be better to just do it in the
> driver.
> 
> > These fail because r300 does not implement the CONT opcode:
> > glsl1-for-loop with continue
> > glsl1-while-loop with continue
> 
> These should be fixed once loop unrolling is implemented.

These three new opcodes shouldn't be a problem for us to implement.
r300 also has D2A and the code is already there to send the "continue"
instruction to the hardware, it just needs to be translated from TGSI.

> 
> > This one was fixed in master after master was merged into glsl2:
> > glsl1-discard statement in for loop
> > 
> > Not sure why this fails yet:
> > glsl-fs-loop-nested
> 
> This might also be unrolling related.  Some more data would be good.

These are almost certainly bugs in the r300 compiler that were uncovered
by glsl2 generating a different instruction sequence.  I don't think you
need to worry about these.

> 
> > These fail on both r300g and llvmpipe with this error:
> > tgsi/tgsi_ureg.c:746:ureg_emit_src: Assertion `src.File != TGSI_FILE_OUTPUT' failed.
> > 
> > glsl-orangebook-ch06-bump
> > glsl-deadcode-varying
> 
> I guess that hardware can't read back outputs that have been written?
> Ugh.  I'm not sure what to do about that one.  Maybe a lowering pass to
> generate writes to a shadow copy that can be read?
> 

I'm not sure if this is a hardware limitation, or a limitation imposed
by gallium, maybe someone who knows gallium a little better will be able
to suggest a solution.

-Tom