From patchwork Tue Apr 3 10:52:24 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: 10320945 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 2747360318 for ; Tue, 3 Apr 2018 10:52:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 080B5204C2 for ; Tue, 3 Apr 2018 10:52:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F0C0A212DA; Tue, 3 Apr 2018 10:52:40 +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 A8BDD204C2 for ; Tue, 3 Apr 2018 10:52:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7B4616E373; Tue, 3 Apr 2018 10:52:38 +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 C12EC6E344 for ; Tue, 3 Apr 2018 10:52:36 +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:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,400,1517904000"; d="scan'208";a="43601296" 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:35 -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:24 +0300 Message-Id: <1522752747-7836-3-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 2/5] i915: add a text about what happens at bottom of stack in processing a batchbuffer 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 Now that "DOC: User command execution" of i915_gem_execbuffer.c is included in the i915.rst, it is benecifial (for new developers) to read what happens at the bottom of the driver stack (in terms of bytes written to be read by the GPU) when processing a user-space batchbuffer. Signed-off-by: Kevin Rogovin Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8c170db8495d..1fe5da1fed47 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -81,6 +81,28 @@ enum { * but this remains just a hint as the kernel may choose a new location for * any object in the future. * + * At the level of talking to the hardware, submitting a batchbuffer for the + * GPU to execute is to add content to a buffer from which the HW + * command streamer is reading. + * 1. Add a command to load the HW context. For Logical Ring Contexts, i.e. + * Execlists, this command is not placed on the same buffer as the + * remaining items. + * 2. Add a command to invalidate caches to the buffer. + * 3. Add a batchbuffer start command to the buffer; the start command is + * essentially a token together with the GPU address of the batchbuffer + * to be executed. + * 4. Add a pipeline flush to the buffer. + * 5. Add a memory write command to the buffer to record when the GPU + * is done executing the batchbuffer. The memory write writes the + * global sequence number of the request, `i915_request::global_seqno``; + * the i915 driver uses the current value in the register to determine + * if the GPU has completed the batchbuffer. + * 6. Add a user interrupt command to the buffer. This command instructs + * the GPU to issue an interrupt when the command, pipeline flush and + * memory write are completed. + * 7. Inform the hardware of the additional commands added to the buffer + * (by updating the tail pointer). + * * Processing an execbuf ioctl is conceptually split up into a few phases. * * 1. Validation - Ensure all the pointers, handles and flags are valid.