On Fri, Nov 6, 2015 at 5:38 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxxxxx> 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. Yes, that looks better. Thanks, Kristian > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
