[Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

Chris Wilson chris at chris-wilson.co.uk
Fri Nov 6 05:38:34 PST 2015


On Thu, Nov 05, 2015 at 10:17:56AM -0800, Jesse Barnes wrote:
> On 11/05/2015 09:51 AM, Kristian Høgsberg wrote:
> > On Tue, Oct 6, 2015 at 3:53 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> Userspace can pass in an offset that it presumes the object is located
> >> at. The kernel will then do its utmost to fit the object into that
> >> location. The assumption is that userspace is handling its own object
> >> locations (for example along with full-ppgtt) and that the kernel will
> >> rarely have to make space for the user's requests.
> > 
> > I know the commit message isn't documentation, but the phrase "do its
> > utmost" makes me uncomfortable. I'd like to be explicit about what
> > might make it fail (should only be pinned fbs in case of aliased ppgtt
> > or userspace errors such as overlapping placements), or conversely,
> > spell out when the flag can be expected to work (full ppgtt).
> 
> Ooh yeah that would be good to add to the execbuf man page with the
> softpin additions.  Oh wait, we don't have a man page for execbuf?
> Someone should write one!

How about:

    This extends the DRM_I915_GEM_EXECBUFFER2 ioctl to do the following:
    * if the user supplies a virtual address via the execobject->offset
      *and* sets the EXEC_OBJECT_PINNED flag in execobject->flags, then
      that object is placed at that offset in the address space selected
      by the context specifier in execbuffer.
    * the location must be aligned to the GTT page size, 4096 bytes
    * as the object is placed exactly as specified, it may be used in this batch
      without relocations pointing to it
    
    It may fail to do so if:
    * EINVAL is returned if the object does not have a 4096 byte aligned
      address
    * the object conflicts with another pinned object (either pinned by
      hardware in that address space, e.g. scanouts in the aliasing ppgtt)
      or within the same batch.
      EBUSY is returned if the location is pinned by hardware
      EINVAL is returned if the location is already in use by the batch
    * EINVAL is returned if the object conflicts with its own alignment (as meets
      the hardware requirements) or if the placement of the object does not fit
      within the address space
    
    All other execbuffer errors apply.

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list