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

[Jesse Barnes]

On Mon, 15 Jun 2009 11:04:56 -0700
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.

After more testing and thinking about this today, I think more
extensive changes are needed.  The DRI driver needs to set the pitch
and size to appropriate values, or tiling won't be enabled (this
happens by default with this patchset since the objects are mostly
smaller than the minimum required size of 1M).  In order to avoid
wasting ridiculous amounts of space, I think we need to distinguish
between objects we need to map or 2D blit with, vs objects we're just
going to do 3D ops with.  The former will need to be fenecable, while
the latter only need to have a power of two pitch.

That means if tiling or usage changes on an object, we may need to
unpin and re-pin in execbuf (pin & relocate) before continuing, in
order to meet fence reg requirements.

Anyone have other thoughts?

-- 
Jesse Barnes, Intel Open Source Technology Center