[Mesa-dev] [PATCH v2 1/2] anv: Add support for 48-bit addresses

[Chris Wilson]

On Wed, Mar 29, 2017 at 04:51:12PM +0100, Chris Wilson wrote:
> On Wed, Mar 29, 2017 at 08:36:36AM -0700, Jason Ekstrand wrote:
> >    On Wed, Mar 29, 2017 at 1:51 AM, Chris Wilson
> >    <[1]chris at chris-wilson.co.uk> wrote:
> >      > diff --git a/src/intel/vulkan/anv_private.h
> >      b/src/intel/vulkan/anv_private.h
> >      > index 27c887c..425e376 100644
> >      > --- a/src/intel/vulkan/anv_private.h
> >      > +++ b/src/intel/vulkan/anv_private.h
> >      > @@ -299,11 +299,34 @@ struct anv_bo {
> >      >      * writing to them and synchronize uses on other rings (eg if the
> >      display
> >      >      * server uses the blitter ring).
> >      >      */
> >      > -   bool is_winsys_bo;
> >      > +   bool is_winsys_bo:1;
> >      > +
> >      > +   /* Whether or not this BO supports having a 48-bit address.  Not
> >      all
> >      > +    * buffers support arbitrary 48-bit addresses.  In particular, we
> >      need to
> >      > +    * be careful with general and instruction state buffers because
> >      we set the
> >      > +    * size in STATE_BASE_ADDRESS to 0xfffff (the maximum) even though
> >      the BO
> >      > +    * is most likely significantly smaller.  If we let the kernel
> >      place it
> >      > +    * anywhere it wants, it will default to placing it as high up the
> >      address
> >      > +    * space as possible, the range specified by STATE_BASE_ADDRESS
> >      will
> >      > +    * over-flow the 48-bit address range, and the GPU will hang.  In
> >      order to
> >      > +    * avoid this problem, we tell the kernel that the buffer does not
> >      support
> >      > +    * 48-bit addresses, and it places the buffer at a 32-bit
> >      address.  While
> >      > +    * this solution is probably overkill, it is effective.
> > 
> >      How about just setting the field to the bo->size? You must know the bo
> >      already at that point so that you can set the relocation target.
> > 
> >    Actually, we don't.  We have a pointer to a thing that claims to be a BO
> >    but the actual GEM handle and size aren't known until execbuf time.  (Yes,
> >    that's a bit weird but there are good reasons for it and it's not likely
> >    to change.  When we stop doing relocations, there's a separate plan for
> >    how to handle that.)
> 
> Hmm. I honestly didn't expect that.

Since you have the machinery to resolve the relocations after the fact,
you could treat the size field as a different type of patching. Just
an idea to resolve the placement restriction later.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre