[Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size

[Chris Wilson]

On Tue, May 23, 2017 at 02:57:16PM +0100, Matthew Auld wrote:
> On 23 May 2017 at 13:54, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Tue, May 23, 2017 at 01:42:56PM +0100, Matthew Auld wrote:
> >> On 16 May 2017 at 10:59, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> > This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;
> >> But wouldn't this assume that sg->length is exactly a page size, I
> >> would have imagined it would be possible for shmem to give us two or
> >> more continuous super-pages, or am I missing something?
> >
> > I'd actually report obj->mm.phys_page_sizes = sg_mask; and cook a value for
> > obj->mm.gtt_pages_sizes:
> >
> >         obj->mm.gtt_page_sizes = 0;
> >         for_each_set_bit(bit, &i915->info.supported_gtt_pages_size) { // add salt
> >                 if (obj->mm.phys_page_sizes & ~0u << bit)
> >                         obj->mm.gtt_page_sizes |= BIT(bit);
> >         }
> Nifty.
> 
> So in mixed-mode what would be the alignment strategy? Align to
> largest, smallest, don't align at all etc. For example if we were
> unlucky and got something like 4K->2M? The obj->mm.gtt_page_sizes
> should always be representative of how we end up inserting it into the
> gtt, right? Would it not be more apt to move the gtt_page_sizes
> tracking to when we do the insert?

My first thought was align to worst (and then hope for the best, i.e.
that we can make use of that alignment, I'm still thinking even if we
get a huge physical page, wasting that alignment in a 48b aperture still
isn't terrible -- caveats if we need to fit inside the low 4G!).
Reporting the actual GTT sizes used might be useful for debug, but the
focus should be on tracking the values that make the code simpler :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre