On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca <jfons...@vmware.com> wrote:
>
>
> ----- Original Message -----
>> On 11/13/2011 03:06 AM, Vadim Girlin wrote:
>> > Hi,
>> >
>> > I found some problem with glsl_to_tgsi: remove_output_reads
>> > function.
>> > It's replacing outputs with temps, producing incorrect results with
>> > relative addressing. You can see it e.g. with
>> > "vs-varying-array-mat2-col-rd.shader_test". Here is a dump:
>> >
>> >> VERT
>> >> DCL IN[0]
>> >> DCL OUT[0], POSITION
>> >> DCL OUT[1], GENERIC[12]
>> >> DCL OUT[2], GENERIC[13]
>> >> DCL OUT[3], GENERIC[14]
>> >> DCL OUT[4], GENERIC[15]
>> >> DCL OUT[5], GENERIC[16]
>> >> DCL OUT[6], GENERIC[17]
>> >> DCL OUT[7], GENERIC[18]
>> >> DCL CONST[0..5]
>> >> DCL TEMP[0..1]
>> >> DCL ADDR[0]
>> >> IMM FLT32 { 1.0000, 2.0000, 3.0000, 4.0000}
>> >> IMM FLT32 { 5.0000, 6.0000, 7.0000, 8.0000}
>> >> IMM FLT32 { 9.0000, 10.0000, 11.0000, 12.0000}
>> >> IMM FLT32 { 0.0000, 1.0000, 0.0000, 0.0000}
>> >> 0: MUL TEMP[0], CONST[2], IN[0].xxxx
>> >> 1: MAD TEMP[1], CONST[3], IN[0].yyyy, TEMP[0]
>> >> 2: MAD TEMP[1], CONST[4], IN[0].zzzz, TEMP[1]
>> >> 3: MAD OUT[0], CONST[5], IN[0].wwww, TEMP[1]
>> >> 4: MOV OUT[2], IMM[0].xyyy
>> >> 5: MOV OUT[3], IMM[0].zwww
>> >> 6: MOV TEMP[0], IMM[1].xyyy
>> >
>> > OUT[2-7] is a "varying mat2x2[3] m;", OUT[4] is replaced with the
>> > temp
>> > in the instruction 6.
>> >
>> >> 7: MOV OUT[5], IMM[1].zwww
>> >> 8: MOV OUT[6], IMM[2].xyyy
>> >> 9: MOV OUT[7], IMM[2].zwww
>> >> 10: ARL ADDR[0].x, CONST[1].xxxx
>> >> 11: SNE TEMP[1], TEMP[ADDR[0].x].xyyy, CONST[0].xyyy
>> >
>> > Instruction 11 contains the read with the relative addressing using
>> > this temp, which is incorrect.
>> >
>> > I'm not sure how to fix it, but AFAICS at least for r600g this step
>> > could be skipped completely - r600 can read outputs without any
>> > problem, they are located in the general-purpose registers.
>> > Removing
>> > calls to remove_output_reads and assert(src.File !=
>> > TGSI_FILE_OUTPUT)
>> > in the ureg_emit_src produces correct result and test passes on
>> > evergreen (total number of fixed tests is about 60).
>> >
>> > Probably it makes sense to make this step optional and ask the
>> > driver
>> > whether to use it, if I'm not missing something?
>>
>> I'd say the right answer is to make a lowering pass that operates on
>> the
>> GLSL IR, *NOT* on TGSI.
>
>> The st_glsl_to_tgsi does a lot of operations
>> on
>> TGSI IR that would be much easier and be much better suited to the
>> higher-level IR.
>
> Yes. I seldom touched the st_foo_to_tgsi.c but always thought to my self that
> IR manipulation should had happened before the TGSI translation. However it
> was not clear if things were done as they are because of unfamiliarity with
> glsl internals, or some limitation in glsl passes.
>
> For example, reusing temporaries registers (so that the total number of
> temporaries is minimized), could this be done in a glsl pass?
The tricky part is that we use TGSI for more than just GLSL. The pipe
video stuff and eventually compute, etc.
Alex
>
> Jose
> _______________________________________________
> 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
