From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2C90973783 for ; Tue, 2 Nov 2021 19:19:59 +0000 (UTC) Date: Tue, 02 Nov 2021 12:18:01 -0700 Message-ID: <871r3ymknq.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" In-Reply-To: <688f0a5a-c1c1-97d8-1f75-e8a69a0fa8e2@intel.com> References: <8da5f8f799245a0dac45ea96c0a3f992a285352e.1635395331.git.ashutosh.dixit@intel.com> <87pmrosmc6.wl-ashutosh.dixit@intel.com> <688f0a5a-c1c1-97d8-1f75-e8a69a0fa8e2@intel.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [igt-dev] [PATCH i-g-t 1/3] lib/i915: Return actual submission method from gem_submission_method List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" To: John Harrison Cc: igt-dev@lists.freedesktop.org List-ID: On Fri, 29 Oct 2021 17:42:19 -0700, John Harrison wrote: > > On 10/28/2021 17:31, Dixit, Ashutosh wrote: > > On Thu, 28 Oct 2021 16:55:32 -0700, John Harrison wrote: > >> On 10/27/2021 21:40, Ashutosh Dixit wrote: > >>> gem_submission_method() purports to return the currently used submission > >>> method by the kernel, as evidenced by its callers. Therefore remove the > >>> GEM_SUBMISSION_EXECLISTS flag when GuC submission is detected. > >>> > >>> This also fixes gem_has_execlists() to match its description, previously > >>> gem_has_execlists() would return true even if GuC submission was actually > >>> being used in the driver. > >>> > >>> v2: Or gem_has_execlists call-sites with gem_has_guc_submission to make the > >>> new code equivalent to the previous code. > >>> v3: Clarify that submission method is either guc (0x4), execlists (0x2) or > >>> legacy without semaphores (0x0) or legacy with semaphores (0x1) > >> What about GuC with semaphores vs GuC without semaphores? Likewise execlist. > >> > >> Semaphores is not a submission method. They are a submission feature whose > >> support or lack there of is independent of the submission method. > > Sorry I didn't know that. But if you see gem_submission_method() in current > > upstream IGT (pasted below) it doesn't return "GuC with semaphores' or > > "execlist with semaphores" either. Anyway, let me do this in the next > > rev. Thanks. > I mean that in the old code: > "GuC with semaphores" == is_guc_submission() && has_semaphores() > > But if you conflate semaphores with the submission method then you have to > explicitly enumerate all combinations. > > Hmm, okay. Just realised that the old code did indeed have > GEM_SUBMISSION_SEMAPHORES. Not sure what that was about!? You can > definitely have semaphores with GuC/execlists and you can definitely have > GuC/execlists without semaphores. I don't see why ring buffer submission > would be any different but I admit it's been a while since I've looked at > any ring buffer code. > > It doesn't look like anything was actually using 'gem_has_semaphores()' at > all, though. So nothing would notice if it was removed ;). I think I am going to do this. Also, has_semaphores() calls here in i915: int i915_getparam_ioctl() { ... case I915_PARAM_HAS_SEMAPHORES: value = !!(i915->caps.scheduler & I915_SCHEDULER_CAP_SEMAPHORES); break; But appears I915_SCHEDULER_CAP_SEMAPHORES bits are never set in caps.scheduler so has_semaphores() should always be returning zero.