From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C460AC33CB1 for ; Wed, 15 Jan 2020 15:57:31 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A60DD2187F for ; Wed, 15 Jan 2020 15:57:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A60DD2187F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0DD896EA03; Wed, 15 Jan 2020 15:57:31 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3ACD96EA03 for ; Wed, 15 Jan 2020 15:57:28 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 07:57:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,323,1574150400"; d="scan'208";a="305542152" Received: from dceraolo-mobl.amr.corp.intel.com (HELO [10.251.133.153]) ([10.251.133.153]) by orsmga001.jf.intel.com with ESMTP; 15 Jan 2020 07:57:27 -0800 To: Chris Wilson , intel-gfx@lists.freedesktop.org References: <20200115013143.34961-1-daniele.ceraolospurio@intel.com> <157907760539.5559.7281364125701103353@skylake-alporthouse-com> From: Daniele Ceraolo Spurio Message-ID: Date: Wed, 15 Jan 2020 07:57:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <157907760539.5559.7281364125701103353@skylake-alporthouse-com> Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH 0/7] Commit early to GuC X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 1/15/2020 12:40 AM, Chris Wilson wrote: > Quoting Daniele Ceraolo Spurio (2020-01-15 01:31:36) >> We currently wait until we attempt to load the GuC to confirm if we're >> in GuC mode or not, at which point a lot of the engine setup has already >> happened and needs to be updated for GuC submission. To allow us to get >> the setup done directly into GuC mode, we need to commit to using GuC >> as soon as possible. > I think this is the wrong direction; as I thought the goal was to allow > delayed loading of firmware, even going as far as allowing the system to > run a browser for the user to get the firmware first. I may be We do indeed want to keep supporting execlists mode even as some HW features move to the GuC to allow the user to get to the binaries, but we don't want to switch between the 2 modes without a reboot. Switching between the 2 modes is not a HW capability that we're committed to; the guc->elsp transition is already not possible, while the elsp->guc one still seems to work, but who knows for how long it will? This series is also not really changing the commitment at the implementation level, just making it "official" and acting based on that. Even without these patches, if the blobs are on the system we will attempt to get into GuC mode unless we get an allocation failure or something similar, in which case it is extremely likely that the fall-back to non-guc will not work either. > completely wrong about that, but imho I never want to have to build > firmware images into the kernel. I do 100% agree with this statement, although I'm not sure how this relates to the series. Are you planning to pull some of the engine setup to an even earlier point? > > The transition from execlists to guc could be just set-wedged; delete > old engines, build guc engines. [This should also work for guc -> guc.] > Throwing away context state is ugly, but simple enough. As mentioned above, we can't switch between elsp and GuC modes so this transition would have to be done before the first submission to HW. Why not go directly in GuC mode then? Daniele > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx