From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepak S Subject: Re: [PATCH 0/4] Introduce a new create ioctl for user specified Date: Tue, 29 Jul 2014 08:34:01 +0530 Message-ID: <53D70F21.4090900@linux.intel.com> References: <1403258530-12548-1-git-send-email-sourab.gupta@intel.com> <1404651540.8759.3.camel@sourabgu-desktop> <1405331676.8759.9.camel@sourabgu-desktop> <20140725084333.GR4747@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 0C4D66E2CF for ; Sun, 27 Jul 2014 20:09:13 -0700 (PDT) In-Reply-To: <20140725084333.GR4747@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , "Gupta, Sourab" Cc: Daniel Vetter , "intel-gfx@lists.freedesktop.org" , "Goel, Akash" List-Id: intel-gfx@lists.freedesktop.org On Friday 25 July 2014 02:13 PM, Daniel Vetter wrote: > On Mon, Jul 14, 2014 at 09:53:38AM +0000, Gupta, Sourab wrote: >> On Sun, 2014-07-06 at 18:29 +0530, sourab gupta wrote: >>> 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 >> Hi, >> Can you please review this patch series. > So on a quick look the kernel side looks sane. The async blitter clear > will have integration issues with the execlist stuff, so having a cpu > clear might be useful and adding the blt clear as a second step. Please > coordinate with the execlist owner. + Thomas to help us with this. > What's definitely missing is igt coverage. I think we need at least: > - Basic ioctl coverage for create2, including cross-checking with older > ioctls. > - Testcase for stolen memory including checking that impossible operations > are all caught correctly. > - Exercising the stolen reaping of purgeable objects. > - Checking that stolen objects are properly cleared. > > See http://blog.ffwll.ch/2013/11/testing-requirements-for-drmi915.html for > general testing requirements and > http://blog.ffwll.ch/2013/11/botching-up-ioctls.html for the special > considerations ioctls require. > > Thanks, Daniel