[Intel-gfx] [RFC] execbuf2 support to avoid fence register allocation

[Jesse Barnes]

On Tue, 30 Jun 2009 21:11:23 -0400
Kristian Høgsberg <krh at bitplanet.net> wrote:

> On Mon, Jun 15, 2009 at 2:04 PM, Jesse
> Barnes<jbarnes at virtuousgeek.org> wrote:
> > We'd like to enable texture tiling on pre-965, but for it to be a
> > win we also need to avoid allocating fence registers for textures.
> >  Even on pre-965 we have 3D command bits that can help us avoid the
> > use of fences, and since 915 and before only have 8, it's pretty
> > important to do so.
> >
> > I'm still in the process of testing this patchset, but at this
> > point it no longer crashes in the various config possibilities (new
> > execbuf2 path on both 965+ and pre-965, old path on both), and
> > seems to allocate/avoid allocating fence regs in various cases as
> > well.
> >
> > I'm definitely open to suggestions on how to improve this.  The
> > libdrm side probably needs the most work; I could probably share
> > more code and I'm still working on getting the fence register count
> > correct in the reloc processing code.
> 
> Still haven't looked closely, but just though of one comment.  We
> don't need the num_cliprects, cliprects_ptr, DR1 and DR4 fields in the
> execbuffer2 struct do we?

Those are still used in the actual dispatch on both paths...  if we
wanted to kill the box stuff it would mean a new dispatch function I
guess.

-- 
Jesse Barnes, Intel Open Source Technology Center