All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mateo Lozano, Oscar" <oscar.mateo@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 06/50] drm/i915: s/intel_ring_buffer/intel_engine
Date: Mon, 19 May 2014 10:02:07 +0000	[thread overview]
Message-ID: <92648605EABDA246B775AAB04C95A7A3012EF79A@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <20140515205218.GX8790@phenom.ffwll.local>

Hi Daniel,

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, May 15, 2014 9:52 PM
> To: Mateo Lozano, Oscar
> Cc: Lespiau, Damien; Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> s/intel_ring_buffer/intel_engine
> 
> On Thu, May 15, 2014 at 02:17:23PM +0000, Mateo Lozano, Oscar wrote:
> > > -----Original Message-----
> > > From: Lespiau, Damien
> > > Sent: Wednesday, May 14, 2014 2:26 PM
> > > To: Daniel Vetter
> > > Cc: Mateo Lozano, Oscar; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH 06/50] drm/i915:
> > > s/intel_ring_buffer/intel_engine
> > >
> > > On Tue, May 13, 2014 at 03:28:27PM +0200, Daniel Vetter wrote:
> > > > On Fri, May 09, 2014 at 01:08:36PM +0100, oscar.mateo@intel.com
> wrote:
> > > > > From: Oscar Mateo <oscar.mateo@intel.com>
> > > > >
> > > > > In the upcoming patches, we plan to break the correlation
> > > > > between engines (a.k.a. rings) and ringbuffers, so it makes
> > > > > sense to refactor the code and make the change obvious.
> > > > >
> > > > > No functional changes.
> > > > >
> > > > > Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
> > > >
> > > > If we rename stuff I'd vote for something close to Bspec language,
> > > > like CS. So maybe intel_cs_engine?
> >
> > Bikeshedding much, are we? :)
> > If we want to get closer to bspecish, intel_engine_cs would be better.
> 
> I'm ok with that too ;-)
> 
> > > Also, can we have such patches (and the like of "drm/i915:
> > > for_each_ring") pushed early when everyone is happy with them, they
> > > cause constant rebasing pain.
> >
> > I second that motion!
> 
> Fully agreed - as soon as we have a rough sketch of where we want to go to I'll
> pull in the rename. Aside I highly suggest to do the rename with coccinelle and
> regerate it on rebases - that's much less error-prone than doing it by hand.
> -Daniel

I propose the following code refactoring at a minimum. Even if I abstract away all the "i915_gem_context.c" and "intel_ringbuffer.c" functionality, and part of "i915_gem_execbuffer.c", to keep changes to legacy code to a minimum, I still think the following changes are good for the overall code:

1)	s/intel_ring_buffer/intel_engine_cs

Straight renaming: if the actual ring buffers can live either inside the engine/ring (legacy ringbuffer submission) or inside the context (execlists), it doesn´t make sense that the engine/ring is called "intel_ring_buffer".

2)	Split the ringbuffers and the rings

New struct:

+struct intel_ringbuffer {
+       struct drm_i915_gem_object *obj;
+       void __iomem *virtual_start;
+
+       u32 head;
+       u32 tail;
+       int space;
+       int size;
+       int effective_size;
+
+       /** We track the position of the requests in the ring buffer, and
+        * when each is retired we increment last_retired_head as the GPU
+        * must have finished processing the request and so we know we
+        * can advance the ringbuffer up to that position.
+        *
+        * last_retired_head is set to -1 after the value is consumed so
+        * we can detect new retirements.
+        */
+       u32 last_retired_head;
+};

And "struct intel_engine_cs" now groups all these elements into "buffer":

-       void            __iomem *virtual_start;
-       struct          drm_i915_gem_object *obj;
-       u32             head;
-       u32             tail;
-       int             space;
-       int             size;
-       int             effective_size;
-       u32             last_retired_head;
+       struct intel_ringbuffer buffer;

3)	Introduce one context backing object per engine

-       struct drm_i915_gem_object *obj;
+       struct {
+               struct drm_i915_gem_object *obj;
+       } engine[I915_NUM_RINGS];

Legacy code only ever uses engine[RCS], so I can use it everywhere in the existing code.

If we agree on this minimum set, I´ll send the patches right away.

Cheers,
Oscar 

  reply	other threads:[~2014-05-19 10:02 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 12:08 [PATCH 00/50] Execlists v2 oscar.mateo
2014-05-09 12:08 ` [PATCH 01/50] drm/i915: s/for_each_ring/for_each_active_ring oscar.mateo
2014-05-09 12:08 ` [PATCH 02/50] drm/i915: for_each_ring oscar.mateo
2014-05-13 13:25   ` Daniel Vetter
2014-05-19 16:33   ` Volkin, Bradley D
2014-05-19 16:36     ` Mateo Lozano, Oscar
2014-05-09 12:08 ` [PATCH 03/50] drm/i915: Simplify a couple of functions thanks to for_each_ring oscar.mateo
2014-05-09 12:08 ` [PATCH 04/50] drm/i915: Extract trivial parts of ring init (early init) oscar.mateo
2014-05-13 13:26   ` Daniel Vetter
2014-05-13 13:47     ` Chris Wilson
2014-05-14 11:53     ` Mateo Lozano, Oscar
2014-05-14 12:28       ` Daniel Vetter
2014-05-09 12:08 ` [PATCH 05/50] drm/i915: Extract ringbuffer destroy, make destroy & alloc outside accesible oscar.mateo
2014-05-09 12:08 ` [PATCH 06/50] drm/i915: s/intel_ring_buffer/intel_engine oscar.mateo
2014-05-13 13:28   ` Daniel Vetter
2014-05-14 13:26     ` Damien Lespiau
2014-05-15 14:17       ` Mateo Lozano, Oscar
2014-05-15 20:52         ` Daniel Vetter
2014-05-19 10:02           ` Mateo Lozano, Oscar [this message]
2014-05-19 12:20             ` Daniel Vetter
2014-05-19 13:41               ` Mateo Lozano, Oscar
2014-05-19 13:52                 ` Daniel Vetter
2014-05-19 14:43                   ` Mateo Lozano, Oscar
2014-05-19 15:11                     ` Daniel Vetter
2014-05-19 15:26                       ` Mateo Lozano, Oscar
2014-05-19 15:49                         ` Daniel Vetter
2014-05-19 16:12                           ` Mateo Lozano, Oscar
2014-05-19 16:24                             ` Volkin, Bradley D
2014-05-19 16:33                               ` Mateo Lozano, Oscar
2014-05-19 16:40                                 ` Volkin, Bradley D
2014-05-19 16:49                                   ` Mateo Lozano, Oscar
2014-05-19 17:00                                     ` Volkin, Bradley D
2014-05-20  8:11                             ` Daniel Vetter
2014-05-09 12:08 ` [PATCH 07/50] drm/i915: Split the ringbuffers and the rings oscar.mateo
2014-05-09 12:08 ` [PATCH 08/50] drm/i915: Rename functions that mention ringbuffers (meaning rings) oscar.mateo
2014-05-09 12:08 ` [PATCH 09/50] drm/i915: Plumb the context everywhere in the execbuffer path oscar.mateo
2014-05-16 11:04   ` Chris Wilson
2014-05-16 11:11     ` Mateo Lozano, Oscar
2014-05-16 11:31       ` Chris Wilson
2014-05-09 12:08 ` [PATCH 10/50] drm/i915: s/__intel_ring_advance/intel_ringbuffer_advance_and_submit oscar.mateo
2014-05-09 12:08 ` [PATCH 11/50] drm/i915: Write a new set of context-aware ringbuffer management functions oscar.mateo
2014-05-09 12:08 ` [PATCH 12/50] drm/i915: Final touches to ringbuffer and context plumbing and refactoring oscar.mateo
2014-05-09 12:08 ` [PATCH 13/50] drm/i915: s/write_tail/submit oscar.mateo
2014-05-09 12:08 ` [PATCH 14/50] drm/i915: Introduce one context backing object per engine oscar.mateo
2014-05-09 12:08 ` [PATCH 15/50] drm/i915: Make i915_gem_create_context outside accessible oscar.mateo
2014-05-09 12:08 ` [PATCH 16/50] drm/i915: Option to skip backing object allocation during context creation oscar.mateo
2014-05-09 12:08 ` [PATCH 17/50] drm/i915: Extract context backing object allocation oscar.mateo
2014-05-09 12:08 ` [PATCH 18/50] drm/i915/bdw: Macro and module parameter for LRCs (Logical Ring Contexts) oscar.mateo
2014-05-09 12:08 ` [PATCH 19/50] drm/i915/bdw: New file for Logical Ring Contexts and Execlists oscar.mateo
2014-05-09 12:08 ` [PATCH 20/50] drm/i915/bdw: Rework init code for Logical Ring Contexts oscar.mateo
2014-05-09 12:08 ` [PATCH 21/50] drm/i915/bdw: A bit more advanced context init/fini oscar.mateo
2014-05-09 12:08 ` [PATCH 22/50] drm/i915/bdw: Allocate ringbuffer backing objects for default global LRC oscar.mateo
2014-05-09 12:08 ` [PATCH 23/50] drm/i915/bdw: Allocate ringbuffer for user-created LRCs oscar.mateo
2014-05-09 12:08 ` [PATCH 24/50] drm/i915/bdw: Populate LR contexts (somewhat) oscar.mateo
2014-05-09 13:36   ` Damien Lespiau
2014-05-12 17:00   ` [PATCH v2 " oscar.mateo
2014-05-09 12:08 ` [PATCH 25/50] drm/i915/bdw: Deferred creation of user-created LRCs oscar.mateo
2014-05-09 12:08 ` [PATCH 26/50] drm/i915/bdw: Allow non-default, non-render, " oscar.mateo
2014-05-13 13:35   ` Daniel Vetter
2014-05-14 11:38     ` Mateo Lozano, Oscar
2014-05-09 12:08 ` [PATCH 27/50] drm/i915/bdw: Status page for LR contexts oscar.mateo
2014-05-09 12:08 ` [PATCH 28/50] drm/i915/bdw: Enable execlists in the hardware oscar.mateo
2014-05-09 12:08 ` [PATCH 29/50] drm/i915/bdw: Execlists ring tail writing oscar.mateo
2014-05-09 12:09 ` [PATCH 30/50] drm/i915/bdw: LR context ring init oscar.mateo
2014-05-09 12:09 ` [PATCH 31/50] drm/i915/bdw: Set the request context information correctly in the LRC case oscar.mateo
2014-05-09 12:09 ` [PATCH 32/50] drm/i915/bdw: GEN8 new ring flush oscar.mateo
2014-05-09 12:09 ` [PATCH 33/50] drm/i915/bdw: Always write seqno to default context oscar.mateo
2014-05-09 12:09 ` [PATCH 34/50] drm/i915/bdw: Implement context switching (somewhat) oscar.mateo
2014-05-09 12:09 ` [PATCH 35/50] drm/i915/bdw: Add forcewake lock around ELSP writes oscar.mateo
2014-05-09 12:09 ` [PATCH 36/50] drm/i915/bdw: Write the tail pointer, LRC style oscar.mateo
2014-05-09 12:09 ` [PATCH 37/50] drm/i915/bdw: Don't write PDP in the legacy way when using LRCs oscar.mateo
2014-05-09 12:09 ` [PATCH 38/50] drm/i915/bdw: LR context switch interrupts oscar.mateo
2014-05-09 12:09 ` [PATCH 39/50] drm/i915/bdw: Get prepared for a two-stage execlist submit process oscar.mateo
2014-05-09 12:09 ` [PATCH 40/50] drm/i915/bdw: Handle context switch events oscar.mateo
2014-06-11 11:52   ` Daniel Vetter
2014-06-11 12:02     ` Mateo Lozano, Oscar
2014-06-11 15:23       ` Mateo Lozano, Oscar
2014-06-12  6:53         ` Daniel Vetter
2014-05-09 12:09 ` [PATCH 41/50] drm/i915/bdw: Start queueing contexts to be submitted oscar.mateo
2014-05-09 12:09 ` [PATCH 42/50] drm/i915/bdw: Display execlists info in debugfs oscar.mateo
2014-05-09 12:09 ` [PATCH 43/50] drm/i915/bdw: Display context backing obj & ringbuffer " oscar.mateo
2014-05-09 12:09 ` [PATCH 44/50] drm/i915/bdw: Print context state " oscar.mateo
2014-05-09 12:09 ` [PATCH 45/50] drm/i915/bdw: Document execlists and logical ring contexts oscar.mateo
2014-05-09 12:09 ` [PATCH 46/50] drm/i915/bdw: Avoid non-lite-restore preemptions oscar.mateo
2014-05-09 12:09 ` [PATCH 47/50] drm/i915/bdw: Make sure gpu reset still works with Execlists oscar.mateo
2014-05-09 12:09 ` [PATCH 48/50] drm/i915/bdw: Make sure error capture keeps working " oscar.mateo
2014-05-09 12:09 ` [PATCH 49/50] drm/i915/bdw: Help out the ctx switch interrupt handler oscar.mateo
2014-06-11 11:50   ` Daniel Vetter
2014-06-11 12:01     ` Mateo Lozano, Oscar
2014-06-11 13:57       ` Daniel Vetter
2014-06-11 14:26         ` Mateo Lozano, Oscar
2014-05-09 12:09 ` [PATCH 50/50] drm/i915/bdw: Enable logical ring contexts oscar.mateo
2014-05-12 17:04 ` [PATCH 49.1/50] drm/i915/bdw: Do not call intel_runtime_pm_get() in an interrupt oscar.mateo
2014-05-13 13:48 ` [PATCH 00/50] Execlists v2 Daniel Vetter

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=92648605EABDA246B775AAB04C95A7A3012EF79A@IRSMSX103.ger.corp.intel.com \
    --to=oscar.mateo@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.