[Mesa-dev] r600g: status of the r600-sb branch

[Christian König]

Am 19.04.2013 18:50, schrieb Vadim Girlin:
> On 04/19/2013 08:35 PM, Christian König wrote:
>> Hey Vadim,
>>
>> Am 19.04.2013 18:18, schrieb Vadim Girlin:
>>> [SNIP]
>>>
>>> In theory, yes, some optimizations in this branch are typically used
>>> on the earlier compilation stages, not on the target machine code. On
>>> the other hand, there are some differences that might make it harder,
>>> e.g. many algorithms require SSA form, and though it's possible to do
>>> similar optimizations without SSA, it would be hard to implement. Also
>>> I wanted to support both default backend and llvm backend for
>>> increased testing coverage and to be able to compare the efficiency of
>>> the algorithms in my experiments etc.
>>
>> Yeah I know, missing an SSA implementation is also something that always
>> bothered me a bit with both TGSI and GLSL (while I haven't done much
>> with GLSL, so maybe I misjudge here).
>>
>> Can you name the different algorithms used?
>
> There is a short description of the algorithms and passes in the 
> notes.markdown file [1] in that branch, there are also links in the 
> end to the full description of some algorithms, though some of them 
> were modified/adapted for this branch.
>
>> It's not a strict prerequisite, but I think we both agree that doing
>> things like LICM on R600 bytecode isn't the best idea over all (when
>> doing it on GLSL would be beneficial for all drivers not only r600).
>
> In fact there is no special LICM pass, it's done by the GCM (Global 
> Code Motion, [2]), which probably could be also called global 
> scheduler. In fact in my branch this pass is combined with some 
> hw-specific scheduling logic, e.g. grouping fetch/alu instructions to 
> reduce clause type switching in the code and the number of required CF 
> instructions, potentially it can also schedule clauses to expose more 
> parallelism with the BARRIER bit usage.
>

Yeah I already thought that you're using something like this.

On one hand that is really good, cause it is specialized on so produces 
really optimal code for the r600 target. But on the other hand it's bad, 
cause it is specialized on so produces really optimal code ONLY on the 
r600 target....

Just speculating, what would it take to make those passes run on the 
LLVM Machine Instruction representation instead of your own representation?

Christian.

> Vadim
>
>  [1] 
> http://cgit.freedesktop.org/~vadimg/mesa/tree/src/gallium/drivers/r600/sb/notes.markdown?h=r600-sb
>  [2] 
> http://www.cs.washington.edu/education/courses/cse501/06wi/reading/click-pldi95.pdf
>
>> Regards,
>> Christian.
>
>