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

Vadim Girlin vadimgirlin at gmail.com
Thu Jan 31 20:56:22 PST 2013

On 02/01/2013 01:53 AM, Marek Olšák wrote:
> Do you plan to merge this branch anytime soon?

Sorry, I almost forgot about that. Though, in theory, I'd like to get 
some testing reports first confirming that it doesn't break everything 
for the non-evergreen chips (I can only test on evergreen), but I guess 
the problems (if any) may be sorted out in master.

I'll rebase updated version on the current master and test if it still 
works without regressions at least on evergreen, then I'll push it, 
probably in a few hours.


> Marek
> On Sat, Dec 29, 2012 at 5:36 PM, Vadim Girlin <vadimgirlin at gmail.com> 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.
>> Vadim
>> _______________________________________________
>> 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