[Mesa-dev] Merge of glsl2 branch to master

Ian Romanick idr at freedesktop.org
Mon Aug 9 19:05:52 PDT 2010


-----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?

> Almost all of the regressions are unimplemented opcodes in the r300
> compiler and shouldn't be a big problem to fix.  I haven't looked into
> the last two regressions, but they appear to be gallium specific.
> 
> -Tom
> 
> P.S. What is the definition of the SSG opcode?  I can't find
> documentation for it.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxgs/wACgkQX1gOwKyEAw80CwCeKf7ZIVFYBuLaYuL/82lTximj
70MAoIMOC4WBG9DQS7MRc/6hdIujvRj2
=S91/
-----END PGP SIGNATURE-----


More information about the mesa-dev mailing list