> -----Original Message----- > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > Sent: Sunday, November 01, 2009 11:06 AM > To: Pierre Ossman > Cc: mesa3d-dev@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-l...@ossman.eu> > wrote: > > I'm looking at r600/r700 compiler with the ambition of filling in the > > missing pieces. I've just read through the documentation and the basic > > structure of the compiler, and I'm having a hard time understanding the > > 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 the > > hardware. The compiler is designed around vectors, whilst the hardware > > works more in terms of individual elements (albeit with a whole bunch > > of restrictions). This disparity means that the compiler in its current > > form can be very inefficient. Worst case scenario is using 25% of the > > 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 simple > > 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 33% > > 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 temporary > > 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 better together. :-) > > 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. > > Alex ------------------------------------------------------------------------------ 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! http://p.sf.net/sfu/devconference _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
