On Mon, Aug 9, 2010 at 8:45 PM, Tom Stellard <tstel...@gmail.com> wrote: > 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.
It's not doc'd AFAIR, but TGSI forbids reading from outputs. (I think i915, r300, and nvfx have this limitation in HW as well, but I can't say for sure.) I haven't looked at ureg in a while, so I don't know if there's a utility that can rewrite to temp for these, or if somebody needs to write one. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <mostawesomed...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
