On 08/10/2010 11:06 AM, Keith Whitwell wrote: > On Mon, 2010-08-09 at 23:48 -0700, Eric Anholt wrote: >> 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. > > 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. > If you throw reads from OUT at my driver it is going to get very angry, as in, stop working. What's next ? Writes to CONST ?
> 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. > > Keith > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
