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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A1E4C433EF for ; Thu, 14 Oct 2021 03:38:44 +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 970F761168 for ; Thu, 14 Oct 2021 03:38:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 970F761168 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 070866E8A3; Thu, 14 Oct 2021 03:38:43 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id 862846E072; Thu, 14 Oct 2021 03:38:41 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10136"; a="313790737" X-IronPort-AV: E=Sophos;i="5.85,371,1624345200"; d="scan'208";a="313790737" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2021 20:38:39 -0700 X-IronPort-AV: E=Sophos;i="5.85,371,1624345200"; d="scan'208";a="524895562" Received: from adixit-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.18.78]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2021 20:38:38 -0700 Date: Wed, 13 Oct 2021 20:21:07 -0700 Message-ID: <878rywi95o.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: John Harrison Cc: , In-Reply-To: <2981474c-7bbc-c76f-6035-f8643f2be547@intel.com> References: <20211013224317.943625-1-John.C.Harrison@Intel.com> <87ily0ilkd.wl-ashutosh.dixit@intel.com> <2981474c-7bbc-c76f-6035-f8643f2be547@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/i915: Skip gem_exec_fair on GuC based platforms 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 13 Oct 2021 18:07:05 -0700, John Harrison wrote: > > On 10/13/2021 15:53, Dixit, Ashutosh wrote: > >> diff --git a/tests/i915/gem_exec_fair.c b/tests/i915/gem_exec_fair.c > >> index ef5a450f6..ca9c73c6e 100644 > >> --- a/tests/i915/gem_exec_fair.c > >> +++ b/tests/i915/gem_exec_fair.c > >> @@ -1314,6 +1314,12 @@ igt_main > >> igt_require(gem_scheduler_enabled(i915)); > >> igt_require(gem_scheduler_has_ctx_priority(i915)); > >> > >> + /* > >> + * These tests are for a specific scheduling model which is > >> + * not currently implemented by GuC. So skip on GuC platforms. > >> + */ > >> + igt_require(intel_gen(intel_get_drm_devid(i915)) < 12); > > Probably a feature check rather than a version check is better? Can we use > > say gem_has_guc_submission() instead? > > > > Though appears gem_has_guc_submission() only checks if guc submission is > > available, not if it is actually in use (unless guc will used when > > available automatically)? Is it possible to add the check if guc submission > > is actually in use? Or a check for guc scheduler? > > I believe this has come up a few times before. My understanding is that no, > there is no current official/safe way for userland to check if GuC > submission is enabled (you can read some of the debugfs files and make an > educated guess but that isn't exactly an official interface). And the > answer was that it isn't worth adding a UAPI specifically for it. Not least > because it would be a UAPI solely for use by IGT which is not allowed. Hmm, so kernel will use GuC submission if bit 0 of enable_guc module param is 1, correct? Which is what gem_has_guc_submission() checks, though I guess we can also add a function gem_using_guc_submission() which is basically an alias for gem_has_guc_submission(). So we can't do this? Or the module param is not an acceptable uapi? But we already introduced gem_has_guc_submission()? I think this kind of a generation/version check should be implemented in the kernel. If kernel wants to turn on GuC submission by default let it do that and set enable_guc. In IGT we just check enable_guc. No? Thanks.