From patchwork Tue Nov 6 04:13:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ankit Navik X-Patchwork-Id: 10669591 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 73F7113BF for ; Tue, 6 Nov 2018 04:13:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5604E2A06E for ; Tue, 6 Nov 2018 04:13:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 44FBC2A071; Tue, 6 Nov 2018 04:13:18 +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=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, 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 DE9482A06E for ; Tue, 6 Nov 2018 04:13:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AB3816E26F; Tue, 6 Nov 2018 04:13:16 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id B88D96E26F for ; Tue, 6 Nov 2018 04:13:15 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 20:13:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,470,1534834800"; d="scan'208";a="278644831" Received: from apnavik-desk.iind.intel.com ([10.66.247.186]) by fmsmga006.fm.intel.com with ESMTP; 05 Nov 2018 20:13:14 -0800 From: Ankit Navik To: intel-gfx@lists.freedesktop.org Date: Tue, 6 Nov 2018 09:43:17 +0530 Message-Id: <1541477601-10883-1-git-send-email-ankit.p.navik@intel.com> X-Mailer: git-send-email 2.7.4 Subject: [Intel-gfx] [PATCH v2 0/4] Dynamic EU configuration of Slice/Subslice/EU. 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: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel Current GPU configuration code for i915 does not allow us to change EU/Slice/Sub-slice configuration dynamically. Its done only once while context is created. While particular graphics application is running, if we examine the command requests from user space, we observe that command density is not consistent. It means there is scope to change the graphics configuration dynamically even while context is running actively. This patch series proposes the solution to find the active pending load for all active context at given time and based on that, dynamically perform graphics configuration for each context. We use a hr (high resolution) timer with i915 driver in kernel to get a callback every few milliseconds (this timer value can be configured through debugfs, default is '0' indicating timer is in disabled state i.e. original system without any intervention).In the timer callback, we examine pending commands for a context in the queue, essentially, we intercept them before they are executed by GPU and we update context with required number of EUs. Two questions, how did we arrive at right timer value? and what's the right number of EUs? For the prior one, empirical data to achieve best performance in least power was considered. For the later one, we roughly categorized number of EUs logically based on platform. Now we compare number of pending commands with a particular threshold and then set number of EUs accordingly with update context. That threshold is also based on experiments & findings. If GPU is able to catch up with CPU, typically there are no pending commands, the EU config would remain unchanged there. In case there are more pending commands we reprogram context with higher number of EUs. Please note, here we are changing EUs even while context is running by examining pending commands every 'x' milliseconds. With this solution in place, on KBL-GT3 + Android we saw following pnp benefits, power numbers mentioned here are system power. App /KPI | % Power | | Benefit | | (mW) | ---------------------------------| 3D Mark (Ice storm) | 2.30% | TRex On screen | 2.49% | TRex Off screen | 1.32% | ManhattanOn screen | 3.11% | Manhattan Off screen | 0.89% | AnTuTu 6.1.4 | 3.42% | Note - For KBL (GEN9) we cannot control at sub-slice level, it was always a constraint. We always controlled number of EUs rather than sub-slices/slices. Praveen Diwakar (4): drm/i915: Get active pending request for given context drm/i915: Update render power clock state configuration for given context drm/i915: set optimum eu/slice/sub-slice configuration based on load type drm/i915: Predictive governor to control eu/slice/subslice drivers/gpu/drm/i915/i915_debugfs.c | 88 +++++++++++++++++++++++++++++- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 10 ++++ drivers/gpu/drm/i915/i915_gem_context.c | 26 +++++++++ drivers/gpu/drm/i915/i915_gem_context.h | 45 +++++++++++++++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 ++ drivers/gpu/drm/i915/intel_device_info.c | 44 ++++++++++++++- drivers/gpu/drm/i915/intel_lrc.c | 20 ++++++- 8 files changed, 235 insertions(+), 4 deletions(-)