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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 082F3C6FA82 for ; Thu, 22 Sep 2022 09:54:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D863510E2BB; Thu, 22 Sep 2022 09:54:35 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9455610E2A4; Thu, 22 Sep 2022 09:54:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663840471; x=1695376471; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=ruTMuVxuSmR3rHbwBxxJPqg3dMI+k+T9N4IDvGz3wc0=; b=LlyKCPka+PGiIGd25erEcGI63Z8HYqemXDLlzY9oQKEeKIu5gFK2UnTG dqZYCVvtd+CWRMxIOwLgeBKvkuOiAJ+9GUt0MbhuvNIKBVigLr0mYGURi G3pHYDtCsZEXhOTalSmw7qp0zIf3V9j+D3oIp+V7ndPYK5UdbQz0qVcRx UYxZLuTpcTXj8szsMxSS/4og/WlKd89V5gmYO7VxjxrORqzeaxK0JvNz4 WT7O4hzbfh48kk0lWT3TjQMWu9aV26+O7Uu6FyHRnvidgXCtfOzzXh22q yH7Bvvz82t/ukhF7LfaKXVqOmxOXUPTk/rdBOiRVH8q05Vgu69MeFRaVk Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10477"; a="364235127" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="364235127" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 02:54:31 -0700 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="864793578" Received: from akoska-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.36.156]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 02:54:26 -0700 From: Jani Nikula To: Niranjana Vishwanathapura , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org In-Reply-To: <20220921070945.27764-9-niranjana.vishwanathapura@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20220921070945.27764-1-niranjana.vishwanathapura@intel.com> <20220921070945.27764-9-niranjana.vishwanathapura@intel.com> Date: Thu, 22 Sep 2022 12:54:09 +0300 Message-ID: <877d1v7n0e.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Intel-gfx] [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions 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: , Cc: paulo.r.zanoni@intel.com, thomas.hellstrom@intel.com, matthew.auld@intel.com, daniel.vetter@intel.com, christian.koenig@amd.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 21 Sep 2022, Niranjana Vishwanathapura wrote: > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h b/driv= ers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h > new file mode 100644 > index 000000000000..725febfd6a53 > --- /dev/null > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h > @@ -0,0 +1,47 @@ > +/* SPDX-License-Identifier: MIT */ > +/* > + * Copyright =C2=A9 2022 Intel Corporation > + */ > + > +#ifndef __I915_GEM_EXECBUFFER_COMMON_H > +#define __I915_GEM_EXECBUFFER_COMMON_H > + > +#include > + > +#include "gt/intel_context.h" You don't need these includes. Most of it can be handled using forward declarations. You'll need > + > +struct eb_fence { > + struct drm_syncobj *syncobj; > + struct dma_fence *dma_fence; > + u64 value; > + struct dma_fence_chain *chain_fence; > +}; > + > +int __eb_pin_engine(struct intel_context *ce, struct i915_gem_ww_ctx *ww, > + bool throttle, bool nonblock); > +void __eb_unpin_engine(struct intel_context *ce); > +int __eb_select_engine(struct intel_context *ce); > +void __eb_put_engine(struct intel_context *context, struct intel_gt *gt); > + > +struct intel_context * > +eb_find_context(struct intel_context *context, unsigned int context_numb= er); > + > +int add_timeline_fence(struct drm_file *file, u32 handle, u64 point, > + struct eb_fence *f, bool wait, bool signal); > +void put_fence_array(struct eb_fence *fences, u64 num_fences); > +int await_fence_array(struct eb_fence *fences, u64 num_fences, > + struct i915_request *rq); > +void signal_fence_array(struct eb_fence *fences, u64 num_fences, > + struct dma_fence * const fence); > + > +int eb_requests_add(struct i915_request **requests, unsigned int num_bat= ches, > + struct intel_context *context, struct i915_sched_attr sched, struct i915_sched_attr is passed by value, so you either need to turn that into a pointer, or you need the definition. The definition is just a wrapper around an int. (For strict type safety or for future proofing or what, I don't know.) And this all brings me to my pet peeve about gem/gt headers. To get that definition of a struct wrapper around an int, you need to include i915_scheduler_types.h, which recursively includes a total of 16 headers. Touch any of those files, and you get a rebuild butterfly effect. 28% of i915 header files, when modified, cause the rebuild of 83% of the driver. Please let's not make it worse. BR, Jani. > + int err); > +void eb_requests_get(struct i915_request **requests, unsigned int num_ba= tches); > +void eb_requests_put(struct i915_request **requests, unsigned int num_ba= tches); > + > +struct dma_fence *__eb_composite_fence_create(struct i915_request **requ= ests, > + unsigned int num_batches, > + struct intel_context *context); > + > +#endif /* __I915_GEM_EXECBUFFER_COMMON_H */ --=20 Jani Nikula, Intel Open Source Graphics Center