[Mesa-dev] r600g shader optimization
vadimgirlin at gmail.com
Sat Oct 8 11:55:03 PDT 2011
On Sat, 2011-10-08 at 11:35 +0200, Christian König wrote:
> Hi Vadim,
> wow quite impressive, does it also contains peep-hole optimisation?
Not yet, I want to create a stable framework first (conversion to the
internal representation and back to the bytecode), and this is still
not finished. Only some simple optimizations which are integrated in
these phases are currently implemented - e.g. dead code elimination.
When this task will be completed, it'll be possible to insert any
optimizations in the middle, using the SSA form, def/use chains and
other precomputed information, and without the need to bother about
most of the hardware specific details.
> I tried to implement that once, but failed because I never got all the
> dependencies between opcodes correctly resolved. Rescheduling export
> instructions and setting the barrier flag of CF instructions correctly
> can also be quite an improvement.
Currently I'm working on global scheduling, and I hope it will handle
> Just a side note in commit "r600g: make some functions in r600_asm.c
> externally accessible" you make a whole bunch of functions externally
> accessible, but didn't add a proper prefix like "r600_" to the function
> name. That could led to a bit confusion when somebody else tries to hack
> on the code.
I'll fix this, though probably I'll use some universal function to
compute all instruction properties once and store them as flags,
instead of using existing is_*_inst functions all over the code.
Checking bank swizzles also should be done in more efficient for my
code way, so I won't need check_and_set_bank_swizzles too. This commit
is a temporary solution.
There is a lot of such things in this code which were implemented in a
quick and simple way just to check if this will work at all, it
will be improved later.
> Am Freitag, den 07.10.2011, 18:14 +0400 schrieb Vadim Girlin:
> > Hi,
> > Recently I've been working on the shader optimization for r600g, and now
> > I have the initial working implementation of simple alu scheduler and
> > register allocator. It has no piglit regressions, though it's still a
> > work in progress and there are known issues with some applications.
> > I've pushed the working branch to github:
> > https://github.com/VadimGirlin/mesa/tree/r600_shader_opt
> > Currently it supports evergreen only, but I'm planning to make it work
> > with other chips too. It uses "struct r600_bytecode" as the source,
> > converting it to SSA-based internal representation. I'm going to
> > implement some optimization passes at that phase, but currently it's
> > then doing final steps - register allocation, alu scheduling, and
> > building new bytecode.
> > I'm attaching as an example the dump for one of the shaders in the
> > glxgears. You could get such dump for all shaders before and after
> > processing by setting R600_OPT_DUMP environment variable to 2. Setting
> > this variable to 1 will only print some information for the processed
> > shaders - size, number of gprs, and number of alu instruction groups.
> > 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