Re: r600/r700 compiler future?
Li, RichardZ <RichardZ.Li <at> amd.com>
2009-11-02 15:35:16 GMT
> -----Original Message-----
> From: Alex Deucher [mailto:alexdeucher <at> gmail.com]
> Sent: Sunday, November 01, 2009 11:06 AM
> To: Pierre Ossman
> Cc: mesa3d-dev <at> lists.sourceforge.net; Li, RichardZ
> Subject: Re: [Mesa3d-dev] r600/r700 compiler future?
> On Sun, Nov 1, 2009 at 9:34 AM, Pierre Ossman <pierre-list <at> ossman.eu>
> > I'm looking at r600/r700 compiler with the ambition of filling in
> > missing pieces. I've just read through the documentation and the
> > structure of the compiler, and I'm having a hard time understanding
> > design choices of the code. Hopefully someone can fill me in on what
> > the plan is here.
> > The basic problem is that the compiler is a somewhat poor fit for
> > hardware. The compiler is designed around vectors, whilst the
> > works more in terms of individual elements (albeit with a whole
> > of restrictions). This disparity means that the compiler in its
> > form can be very inefficient. Worst case scenario is using 25% of
> > hardware.
Yeah, there are 5 micro processor grouped into one vector processor
which intends to process ALU instruction group. Each ALU instruction
group consists of 5 per-component instruction, optionally 2 constants.
ALU instruction groups form the clause.
Surely there could be less per-component instruction in one ALU
instruction group. In any case, the last instruction should set
m_Word0.f.last = 1.
> > As an example, I've been looking at implementing the EXP op. A
> > implementation would use 4 instruction groups with the current
> > compiler, but the hardware should be capable of doing it with 2. An
> > optimised implementation would range in efficiency between 100% and
> > of hardware capability. The common case would probably still be 50%.
Given concept of r6/r7 alu processor, surely we could choose only
effective alu component instruction to emit; we could use write-mask to
do that. In r6/r7 mesa dri driver, there is assemble_alu_instruction to
assemble the alu instructions, where write-mask should be referenced.
> > So what's the plan here? This kind of inefficiency must be a
> > solution and not the final goal?
Yes, you are right. When the compiler code was put there, as Alex said,
we hope to get everything worked. Certainly emit alu instruction based
on write-mask is the must-do tune up for current compiler. We are
preparing compiling capability for r6/r7 driver for mesa glsl IL to hw
instructions. Originally I hoped could tune up compiler after it.
Surely any optimizations are welcome, especially this one. I hope
current code is only a start point for us to make its graphics run
> At this point the compiler is pretty much unoptimized; it was written
> to make sure everything worked. In most cases it just provides the
> basic functionality, so optimizations are welcome. I've cc'ed
> Richard as he has written most of the shader code at this point.
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!