r600/r700 compiler future?

[Pierre Ossman-7]

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.

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%.

So what's the plan here? This kind of inefficiency must be a temporary
solution and not the final goal?

Rgds
--
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Sun, Nov 1, 2009 at 9:34 AM, Pierre Ossman <pierre-list@...> 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.
>
> 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%.
>
> So what's the plan here? This kind of inefficiency must be a temporary
> solution and not the final goal?

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Li, RichardZ]

> -----Original Message-----
> From: Alex Deucher [mailto:alexdeucher@...]
> Sent: Sunday, November 01, 2009 11:06 AM
> To: Pierre Ossman
> Cc: mesa3d-dev@...; Li, RichardZ
> Subject: Re: [Mesa3d-dev] r600/r700 compiler future?
>
> On Sun, Nov 1, 2009 at 9:34 AM, Pierre Ossman <pierre-list@...>
> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Pierre Ossman-7]

I'm sorry this reply is so late. I completely forgot about this
thread...

On Mon, 2 Nov 2009 10:35:16 -0500
"Li, RichardZ" <RichardZ.Li@...> wrote:

>
> 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. :-)
>  

Getting things working first, and then getting them fast is definitely
the right approach. I think everyone is familiar with the evils of
premature optimisations. :)

That said, I think we need to get the basic architecture right or risk
having to rewrite a lot of the compiler when trying to optimise it.

The more I've been thinking about it, the more it feels right to have
the internal representation based around elements as opposed to
vectors. The frontend of the compiler would then generate these element
based operations, and we'd have an instruction scheduler that organises
them efficiently.

In the first version that scheduler would just make sure that
instructions are tagged in a way that gives proper execution. That
shouldn't require any reordering and therefore shouldn't be that messy
to implement. Later we can improve the scheduler to pack instructions
more tightly.

As for Mesa vs Gallium, I guess making a really good compiler is only
important for Gallium as that is the long term solution and Mesa is
just a stop-gap.

I'm not sure how the GLSL compiler you are working on looks like, nor
do I know what design Corbin's Gallium code uses, but I'm hoping we're
all pulling in the same direction. :)

Rgds
--
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Corbin Simpson]

I am only barely just started on r600g, and I think I may be already down the wrong path.

Just like with r300g, sharing compilers would be totally kosher, especially since we have all these different shader types that really should have only one IR and compiler pipeline.

Posting from a mobile, pardon my terseness. ~ C.

On Nov 28, 2009 2:37 AM, "Pierre Ossman" <pierre-list@...> wrote:

I'm sorry this reply is so late. I completely forgot about this
thread...

On Mon, 2 Nov 2009 10:35:16 -0500 "Li, RichardZ" <RichardZ.Li@...> wrote: > > Yes, you are ri...

Getting things working first, and then getting them fast is definitely
the right approach. I think everyone is familiar with the evils of
premature optimisations. :)

That said, I think we need to get the basic architecture right or risk
having to rewrite a lot of the compiler when trying to optimise it.

The more I've been thinking about it, the more it feels right to have
the internal representation based around elements as opposed to
vectors. The frontend of the compiler would then generate these element
based operations, and we'd have an instruction scheduler that organises
them efficiently.

In the first version that scheduler would just make sure that
instructions are tagged in a way that gives proper execution. That
shouldn't require any reordering and therefore shouldn't be that messy
to implement. Later we can improve the scheduler to pack instructions
more tightly.

As for Mesa vs Gallium, I guess making a really good compiler is only
important for Gallium as that is the long term solution and Mesa is
just a stop-gap.

I'm not sure how the GLSL compiler you are working on looks like, nor
do I know what design Corbin's Gallium code uses, but I'm hoping we're
all pulling in the same direction. :)

Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by FRA, a Swedi...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Alex Deucher]

On Sat, Nov 28, 2009 at 5:36 AM, Pierre Ossman <pierre-list@...> wrote:

> I'm sorry this reply is so late. I completely forgot about this
> thread...
>
> On Mon, 2 Nov 2009 10:35:16 -0500
> "Li, RichardZ" <RichardZ.Li@...> wrote:
>
>>
>> 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. :-)
>>
>
> Getting things working first, and then getting them fast is definitely
> the right approach. I think everyone is familiar with the evils of
> premature optimisations. :)
>
> That said, I think we need to get the basic architecture right or risk
> having to rewrite a lot of the compiler when trying to optimise it.
>
> The more I've been thinking about it, the more it feels right to have
> the internal representation based around elements as opposed to
> vectors. The frontend of the compiler would then generate these element
> based operations, and we'd have an instruction scheduler that organises
> them efficiently.
>
> In the first version that scheduler would just make sure that
> instructions are tagged in a way that gives proper execution. That
> shouldn't require any reordering and therefore shouldn't be that messy
> to implement. Later we can improve the scheduler to pack instructions
> more tightly.
>
> As for Mesa vs Gallium, I guess making a really good compiler is only
> important for Gallium as that is the long term solution and Mesa is
> just a stop-gap.
>
> I'm not sure how the GLSL compiler you are working on looks like, nor
> do I know what design Corbin's Gallium code uses, but I'm hoping we're
> all pulling in the same direction. :)

The r600 GLSL code is already in git.  Reviews/thoughts much appreciated.

Alex

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev