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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
