[Mesa-dev] Merge of glsl2 branch to master

Christoph Bumiller e0425955 at student.tuwien.ac.at
Tue Aug 10 10:29:47 PDT 2010

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 <idr at freedesktop.org> wrote:
>>> Hash: SHA1
>>> Tom Stellard wrote:
>>>> On Fri, Aug 06, 2010 at 03:24:50PM -0700, Ian Romanick wrote:
>>>>> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list