[Intel-gfx] [PATCH v2 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()

[Daniel Vetter]

On Wed, Jun 24, 2015 at 08:28:13AM +0100, Chris Wilson wrote:
> On Tue, Jun 23, 2015 at 04:44:52PM -0700, Anuj Phogat wrote:
> > On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > On Mon, Jun 22, 2015 at 09:51:08PM +0200, Daniel Vetter wrote:
> > >> On Mon, Jun 22, 2015 at 11:47:02AM -0700, Anuj Phogat wrote:
> > >> > and use it to initialize the align variable in drm_intel_bo.
> > >> >
> > >> > In case of YF/YS tiled buffers libdrm need not know about the tiling
> > >> > format because these buffers don't have hardware support to be tiled
> > >> > or detiled through a fenced region. But, libdrm still need to know
> > >> > about buffer alignment restrictions because kernel uses it when
> > >> > resolving the relocation.
> > >> >
> > >> > Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
> > >> > So, use the passed alignment value in this function. Note that we continue
> > >> > ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
> > >> > the previous behavior.
> > >> >
> > >> > V2: Add a condition to avoid allocation from cache. (Ben)
> > >>
> > >> This will hurt badly since some programs love to cycle through textures.
> > >> You can still allocate from the cache, you only need to update the
> > >> alignement constraint. The kernel will move the buffer on the next execbuf
> > >> if it's misplaced.
> > >
> > > For llc, using fresh pages just puts memory and aperture pressure (plus
> > > a small amount of interface pressure) on the system by allocating more bo.
> > >
> > > For !llc, it is far better to move an object in the GTT to match a
> > > change in alignment than it is to allocate fresh pages (and deallocate
> > > stale pages).
> > Could you please explain this and point me to what you want to be
> > changed in this patch?
> 
> You can reuse the cached bo if the alignment mismatches. You can
> experiment with searching for a better match, but it's unlikely to be
> useful (numbers talk here).
> 
> Reusing the cache and keeping the working set small (with zero turnover)
> is vital on !llc. Moving a GTT binding is far cheaper than preparing the
> backing store for access with the GPU.

In other words Chris just supported my suggestion to reuse from the bo
cache and just update the alignment with his own experience: It's a lot
faster than allocating new bo, especially on machines lacking llc (like
vlv/chv).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch