[Mesa-dev] Merge of glsl2 branch to master

[Corbin Simpson]

On Mon, Aug 9, 2010 at 8:45 PM, Tom Stellard <tstellar at 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
<MostAwesomeDude at gmail.com>