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

Vadim Girlin vadimgirlin at gmail.com
Fri Feb 1 06:57:47 PST 2013

On 02/01/2013 06:09 PM, Marek Olšák wrote:
> There are no regresssions on RV730.

Great. Thanks for testing it.


> Marek
> On Fri, Feb 1, 2013 at 5:56 AM, Vadim Girlin <vadimgirlin at gmail.com> wrote:
>> 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.
>> Vadim
>>> 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