From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gupta, Sourab" Subject: Re: [PATCH 0/4] Introduce a new create ioctl for user specified Date: Sun, 6 Jul 2014 12:58:02 +0000 Message-ID: <1404651540.8759.3.camel@sourabgu-desktop> References: <1403258530-12548-1-git-send-email-sourab.gupta@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 1EABC6E268 for ; Sun, 6 Jul 2014 05:58:26 -0700 (PDT) In-Reply-To: <1403258530-12548-1-git-send-email-sourab.gupta@intel.com> Content-Language: en-US Content-ID: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "intel-gfx@lists.freedesktop.org" Cc: Daniel Vetter , "Goel, Akash" List-Id: intel-gfx@lists.freedesktop.org On Fri, 2014-06-20 at 10:02 +0000, Gupta, Sourab wrote: > From: Sourab Gupta > > This patch series introduces a new gem create ioctl for user specified > placement. > > 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. > > This new create ioctl therefore exists to allow the user to create these > second class buffer objects from stolen memory. At the moment direct > access by the CPU through mmaps and pread/pwrite are verboten on the > objects, and so the user must be aware of the limitations of the objects > created. Yet, those limitations rarely reduce the desired functionality > in many use cases and so the user should be able to easily fill the > stolen memory and so help to reduce overall memory pressure. > > The most obvious use case for stolen memory is for the creation of objects > for the display engine which already have very similar restrictions on > access. However, we want a reasonably general ioctl in order to cater > for diverse scenarios beyond the author's imagination. > > Chris Wilson (3): > drm/i915: Clearing buffer objects via blitter engine > drm/i915: Introduce a new create ioctl for user specified placement > drm/i915: Add support for stealing purgable stolen pages > > Deepak S (1): > drm/i915: Clearing buffer objects via blitter engine for Gen8 > > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/i915_dma.c | 5 +- > drivers/gpu/drm/i915/i915_drv.h | 18 ++- > drivers/gpu/drm/i915/i915_gem.c | 208 ++++++++++++++++++++++++++++++--- > drivers/gpu/drm/i915/i915_gem_exec.c | 139 ++++++++++++++++++++++ > drivers/gpu/drm/i915/i915_gem_stolen.c | 121 +++++++++++++++++-- > drivers/gpu/drm/i915/i915_gem_tiling.c | 106 +++++++++-------- > include/uapi/drm/i915_drm.h | 107 +++++++++++++++++ > 8 files changed, 623 insertions(+), 82 deletions(-) > create mode 100644 drivers/gpu/drm/i915/i915_gem_exec.c > Hi, Can somebody please review this patch series, alongwith the libdrm changes(http://lists.freedesktop.org/archives/intel-gfx/2014-June/047296.html) and igt (http://lists.freedesktop.org/archives/intel-gfx/2014-June/047295.html) Thanks, Sourab