All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 08/14] drm/i915: Store backpointer to intel_gt in the engine
Date: Tue, 11 Jun 2019 09:41:02 +0100	[thread overview]
Message-ID: <d44bae42-9ccb-2135-7787-3f9efde94000@linux.intel.com> (raw)
In-Reply-To: <1b9b317e-915c-5ffe-e904-cf281a84e972@intel.com>


On 10/06/2019 19:17, Daniele Ceraolo Spurio wrote:
> On 6/10/19 9:16 AM, Chris Wilson wrote:
>> Quoting Tvrtko Ursulin (2019-06-10 16:54:13)
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
>>> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
>>> index 01223864237a..343c4459e8a3 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
>>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
>>> @@ -34,6 +34,7 @@ struct drm_i915_reg_table;
>>>   struct i915_gem_context;
>>>   struct i915_request;
>>>   struct i915_sched_attr;
>>> +struct intel_gt;
>>>   struct intel_uncore;
>>>   typedef u8 intel_engine_mask_t;
>>> @@ -266,6 +267,7 @@ struct intel_engine_execlists {
>>>   struct intel_engine_cs {
>>>          struct drm_i915_private *i915;
>>> +       struct intel_gt *gt;
>>
>> I'd push for gt as being the backpointer, and i915 its distant grand
>> parent. Not sure how much pain that would bring just for the elimination
>> of one more drm_i915_private, but that's how I picture the
>> encapsulation.

It depends on overall direction. Are we going to go with helpers 
(XXX_to_i915) or not. Well for removing engine->i915 there would be 
churn already. But same churn regardless of whether we pick 
engine_to_i915 or engine->gt->i915.

But I don't see a problem with having both i915 and gt pointers in the 
engine. It's a short cut to avoid pointer chasing and verbosity. Our 
code is fundamentally still very dependent on runtime checks against 
INTEL_GEN and INTEL_INFO, so i915 is pretty much in need all over the place.

> Would it be worth moving some of the flags in the device_info structure 
> in a gt substructure, like we did for display, and get a pointer to that 
> in intel_gt? We could save some jumps back that way and be more coherent 
> in where we store the info.

So even with this we maybe reduce the need to chase all the way to i915 
a bit, but not fully. Unless we decide to duplicate gen in intel_gt as 
well. Well.. now I am scared we will just decide to do that. :D

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-06-11  8:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-10 15:54 [RFC v2 00/14] Implicit dev_priv removal Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 01/14] drm/i915: Make i915_check_and_clear_faults take uncore Tvrtko Ursulin
2019-06-10 16:26   ` Chris Wilson
2019-06-11  8:35     ` Tvrtko Ursulin
2019-06-11  8:52       ` Chris Wilson
2019-06-11 12:05         ` Tvrtko Ursulin
2019-06-11 12:12           ` Chris Wilson
2019-06-10 15:54 ` [RFC 02/14] drm/i915: Convert intel_vgt_(de)balloon to uncore Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 03/14] drm/i915: Introduce struct intel_gt as replacement for anonymous i915->gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 04/14] drm/i915: Add a couple intel_gt helpers Tvrtko Ursulin
2019-06-10 16:19   ` Chris Wilson
2019-06-10 15:54 ` [RFC 05/14] drm/i915: Convert i915_gem_init_swizzling to intel_gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 06/14] drm/i915: Convert init_unused_rings " Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 07/14] drm/i915: Convert gt workarounds " Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 08/14] drm/i915: Store backpointer to intel_gt in the engine Tvrtko Ursulin
2019-06-10 16:16   ` Chris Wilson
2019-06-10 18:17     ` Daniele Ceraolo Spurio
2019-06-11  8:41       ` Tvrtko Ursulin [this message]
2019-06-11  9:36         ` Chris Wilson
2019-06-11 16:42           ` Daniele Ceraolo Spurio
2019-06-10 15:54 ` [RFC 09/14] drm/i915: Convert intel_mocs_init_l3cc_table to intel_gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 10/14] drm/i915: Convert i915_ppgtt_init_hw " Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 11/14] drm/i915: Consolidate some open coded mmio rmw Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 12/14] drm/i915: Convert i915_gem_init_hw to intel_gt Tvrtko Ursulin
2019-06-10 15:54 ` [RFC 13/14] drm/i915/guc: Move intel_guc_reserved_gtt_size to intel_wopcm_guc_size Tvrtko Ursulin
2019-06-10 18:29   ` Michal Wajdeczko
2019-06-10 15:54 ` [RFC 14/14] drm/i915: Make GuC GGTT reservation work on ggtt Tvrtko Ursulin
2019-06-10 18:43   ` Michal Wajdeczko
2019-06-10 17:42 ` ✗ Fi.CI.CHECKPATCH: warning for Implicit dev_priv removal (rev2) Patchwork
2019-06-10 17:48 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-06-10 18:05 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-11 23:03 ` ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d44bae42-9ccb-2135-7787-3f9efde94000@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniele.ceraolospurio@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.