From patchwork Tue Apr 3 10:52:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: kevin.rogovin@intel.com X-Patchwork-Id: 10320949 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A315460532 for ; Tue, 3 Apr 2018 10:52:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 82A54204FB for ; Tue, 3 Apr 2018 10:52:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 77223223B2; Tue, 3 Apr 2018 10:52:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 34B4A204FB for ; Tue, 3 Apr 2018 10:52:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1451D6E386; Tue, 3 Apr 2018 10:52:42 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9FCD76E38B for ; Tue, 3 Apr 2018 10:52:40 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 03:52:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,400,1517904000"; d="scan'208";a="43601305" Received: from rdhanapx-mobl3.gar.corp.intel.com (HELO LittleBigTrouble.ger.corp.intel.com) ([10.252.52.1]) by fmsmga001.fm.intel.com with ESMTP; 03 Apr 2018 03:52:38 -0700 From: kevin.rogovin@intel.com To: intel-gfx@lists.freedesktop.org, tvrtko.ursulin@linux.intel.com, abdiel.janulgue@linux.intel.com, joonas.lahtinen@linux.intel.com, chris@chris-wilson.co.uk Date: Tue, 3 Apr 2018 13:52:26 +0300 Message-Id: <1522752747-7836-5-git-send-email-kevin.rogovin@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1522752747-7836-1-git-send-email-kevin.rogovin@intel.com> References: <1522752747-7836-1-git-send-email-kevin.rogovin@intel.com> Subject: [Intel-gfx] [PATCH v4 4/5] i915: correct lazy ringbuffer and backing store documentation X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Rogovin MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP From: Kevin Rogovin Correct documentation of logical ring context implementation to note that ringbuffer and backing store are created lazily for all context types (driver global, local default context and local extra context). Signed-off-by: Kevin Rogovin --- drivers/gpu/drm/i915/intel_lrc.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 53f1c009ed7b..382a4656a1d9 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -70,22 +70,11 @@ * - One ringbuffer per-engine inside each context. * - One backing object per-engine inside each context. * - * The global default context starts its life with these new objects fully - * allocated and populated. The local default context for each opened fd is - * more complex, because we don't know at creation time which engine is going - * to use them. To handle this, we have implemented a deferred creation of LR - * contexts: - * - * The local context starts its life as a hollow or blank holder, that only - * gets populated for a given engine once we receive an execbuffer. If later + * which are populated for a given engine once we receive an execbuffer.If later * on we receive another execbuffer ioctl for the same context but a different * engine, we allocate/populate a new ringbuffer and context backing object and * so on. * - * Finally, regarding local contexts created using the ioctl call: as they are - * only allowed with the render ring, we can allocate & populate them right - * away (no need to defer anything, at least for now). - * * Execlists implementation: * Execlists are the new method by which, on gen8+ hardware, workloads are * submitted for execution (as opposed to the legacy, ringbuffer-based, method).