[Mesa-dev] r600g: RFC: ISA information tables and shader disassembler

[Christian König]

On 29.12.2012 17:36, Vadim Girlin wrote:
> The patches are pretty big so you can find the branch here:
>
> http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-disasm
>
> My primary goal was to have a shader disassembler in the driver to 
> simplify the debugging. The disassembler itself is small, but it 
> relies on the big patch that introduces the tables with ISA 
> information - names of the instructions, opcodes for different chip 
> classes, flags to simplify instruction classification, etc. Although 
> the disassembler needs the names only, I had the complete tables 
> already prepared for other work on shader optimization, so I think 
> that it makes sense to use other stuff as well while I'm at it.
>
> All bytecode structs now contain the indices of instruction records in 
> the tables instead of native opcodes - this allows easy access to all 
> related information in the tables - e.g. number of operands for alu 
> instructions, native opcode for current chip class, etc. Also this 
> allows to use single id for instruction even if it has different 
> opcodes on different chips, that is, e.g. we don't have to check for 
> all possible opcodes to say that current instruction is DOT4, we can 
> simply compare alu->op with ALU_OP2_DOT4 constant that represents the 
> index in the table, so this simplifies the processing of the shader 
> code. Also alu table contains the information about allowed slots 
> (vector/scalar) for different chip classes and some additional flags - 
> e.g. instead of comparing some opcode with all possible KILLxx opcodes 
> we can simply check the flag that is set in the table for all KILLxx 
> instructions.
>
> The branch was tested on evergreen and there are no regressions with 
> both shader backends (llvm and old), but I won't be surprised if there 
> are bugs for another chip classes. I'll appreciate testing on 
> r6xx/r7xx/cayman, but be ready to possible lockups etc.
>
> New disassembler can be activated with R600_DUMP_SHADERS=2.
>
> R600_DUMP_SHADERS=1 still uses old dump method, 3 - produces both 
> dumps for every shader.

Very nice work. Actually that's how I wanted to implement the 
DUMP_SHADERS feature in the first place, but never got the time to 
actually do it.

On the other hand we probably want to move this information sooner or 
later into the LLVM backend and generate the bytecode directly there.

Anyway I would suggest to commit it first and the worry about how to 
move it into llvm later. Also I don't think we still need the older dump 
functionality any more when this is working properly.

Regards,
Christian.