[Intel-gfx] [PATCH v7 0/5] Support for creating/using Stolen memory backed objects
Daniel Vetter
daniel at ffwll.ch
Wed Sep 23 09:03:55 PDT 2015
On Wed, Sep 23, 2015 at 04:21:18PM +0530, ankitprasad.r.sharma at intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
>
> This patch series adds support for creating/using Stolen memory backed
> objects.
>
> Despite being a unified memory architecture (UMA) some bits of memory
> are more equal than others. In particular we have the thorny issue of
> stolen memory, memory stolen from the system by the BIOS and reserved
> for igfx use. Stolen memory is required for some functions of the GPU
> and display engine, but in general it goes wasted. Whilst we cannot
> return it back to the system, we need to find some other method for
> utilising it. As we do not support direct access to the physical address
> in the stolen region, it behaves like a different class of memory,
> closer in kin to local GPU memory. This strongly suggests that we need a
> placement model like TTM if we are to fully utilize these discrete
> chunks of differing memory.
>
> To add support for creating Stolen memory backed objects, we extend the
> drm_i915_gem_create structure, by adding 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.
>
> This patch series adds support for clearing buffer objects via CPU/GTT.
> This is particularly useful for clearing out the memory from stolen
> region, but can also be used for other shmem allocated objects. Currently
> being used for buffers allocated in the stolen region. Also adding support
> for stealing purgable stolen pages, if we run out of stolen memory when
> trying to allocate an object.
>
> v2: Added support for read/write from/to objects not backed by
> shmem using the pread/pwrite interface.
> Also extended the current get_aperture ioctl to retrieve the
> total and available size of the stolen region
>
> v3: Removed the extended get_aperture ioctl patch 5 (to be submitted as
> part of other patch series), addressed comments by Chris about pread/pwrite
> for non shmem backed objects
>
> v4: Rebased to the latest drm-intel-nightly
>
> v5: Addressed comments, replaced patch 1/4 "Clearing buffers via blitter
> engine" by "Clearing buffers via CPU/GTT"
>
> v6: Rebased to the latest drm-intel-nightly, Addressed comments, updated
> stolen memory purging logic by maintaining a list for purgable stolen
> memory objects, enabled pread/pwrite for all non-shmem backed objects
> without tiling restrictions
>
> v7: Addressed comments, compiler optimization, new patch added for correct
> error code propagation to the userspace
>
> This can be verified using IGT tests: igt/gem_stolen, igt/gem_create
>
> Ankitprasad Sharma (4):
> drm/i915: Clearing buffer objects via CPU/GTT
> drm/i915: Support for creating Stolen memory backed objects
> drm/i915: Support for pread/pwrite from/to non shmem backed objects
> drm/i915: Propagating correct error codes to the userspace
>
> Chris Wilson (1):
> drm/i915: Add support for stealing purgable stolen pages
Hm, where's the patch to evict stolen objects to sysmem over
hibernate-to-disk that Chris raised? I guess we need this to avoid
breaking generic linux distros (and atm that's the only open-source user
afaics).
-Daniel
>
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
> drivers/gpu/drm/i915/i915_dma.c | 3 +
> drivers/gpu/drm/i915/i915_drv.h | 20 ++-
> drivers/gpu/drm/i915/i915_gem.c | 216 ++++++++++++++++++++++++++++----
> drivers/gpu/drm/i915/i915_gem_stolen.c | 200 +++++++++++++++++++++++------
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/intel_overlay.c | 4 +-
> drivers/gpu/drm/i915/intel_pm.c | 6 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +-
> include/uapi/drm/i915_drm.h | 16 +++
> 11 files changed, 402 insertions(+), 75 deletions(-)
>
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list