On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sharma@xxxxxxxxx wrote: > From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx> > > Extend the drm_i915_gem_create structure to add support for > creating Stolen memory backed objects. Added a new flag through > which user can specify the preference to allocate the object from > stolen memory, which if set, an attempt will be made to allocate > the object from stolen memory subject to the availability of > free space in the stolen region. > > v2: Rebased to the latest drm-intel-nightly (Ankit) > > v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko) > > v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko) > Corrected function arguments ordering (Chris) > > v5: Corrected function name (Chris) > > v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64 > aligned (Chris) > > v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper > function for object allocation from stolen region (Ankit) > > Testcase: igt/gem_stolen > > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > + /** > + * Requested flags (currently used for placement > + * (which memory domain)) > + * > + * You can request that the object be created from special memory > + * rather than regular system pages using this parameter. Such > + * irregular objects may have certain restrictions (such as CPU > + * access to a stolen object is verboten). > + * > + * This can be used in the future for other purposes too > + * e.g. specifying tiling/caching/madvise > + */ > + __u64 flags; > +#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */ > +#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */ /* Allocate the object from memory reserved for the igfx (stolen). * * Objects allocated from stolen are restricted in the API they can use, * as direct CPU access to stolen memory is prohibited by the system. * This means that you cannot use a regular CPU mmap (either using WB * or with the WC extension). You can still use a GTT mmap, pwrite, * pread and pass it around for use by execbuffer and between processes * like normal. * * Stolen memory is a very limited resource and certain functions of the * hardware can only work from within stolen memory. Userspace's * allocations may be evicted from stolen and moved to normal memory as * required. If the allocation is marked as purgeable (using madvise), * the allocation will be dropped and further access to the object's * backing storage will result in -EFAULT. Stolen objects will also be * migrated to normal memory across suspend and resume, as the stolen * memory is not preserved. * * Stolen memory is regarded as a resource placement hint, most suitable * for medium-sized buffers that are only accessed by the GPU and can be * discarded. */ -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx