On Mon, 09 Aug 2010 19:05:52 -0700, Ian Romanick <i...@freedesktop.org> 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. > > > 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 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?
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.
pgp7mJVfC6X8f.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
