Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 5/5] drm/i915: introduce intel_execlists_submission.<c/h>
Date: Wed, 11 Dec 2019 14:35:05 -0800	[thread overview]
Message-ID: <062ab6cc-ca22-d2cb-7b73-ef5516b04cc3@intel.com> (raw)
In-Reply-To: <157609988550.27099.9421610954504392154@skylake-alporthouse-com>

<snip>


>> +
>> +struct i915_request *
>> +execlists_unwind_incomplete_requests(struct intel_engine_execlists *execlists)
> 
> There should be no exports from this file... Did you not also make
> guc_submission standalone?
> 

The new GuC submission code will have its own 
_unwind_incomplete_requests function, just didn't seem worth it copying 
this to the GuC file now to make this static and get rid of it later. 
The current version of the GuC patches (being worked on by Matt) is also 
not yet fully standalone, but we're moving into that direction.


<snip>

>> +bool
>> +intel_engine_in_execlists_submission_mode(const struct intel_engine_cs *engine)
>> +{
>> +       return engine->set_default_submission ==
>> +              intel_execlists_set_default_submission;
>> +}
> 
> The breadcrumb submission code is specialised to execlists and should
> not be shared (leaves emit_flush, emit_bb_start as common
> gen8_submission.c). The reset code is specialised to execlists and should not
> be shared. The virtual engine is specialised to execlists and should not
> be shared. Even submit_request should be distinct between guc and
> execlists, especially request_alloc (which you may like to put on the
> context_ops rather than engine)
> -Chris
> 

engine->reset.*, request_alloc and submit_request have all been moved to 
execlists_submission.c in this patch, with the aim of not sharing them.

For the virtual engine, I've moved the submission related chunks to 
execlists_submission.c as well (see the new 
intel_execlists_virtual_submission_init, although I could probably move 
a few extra bits in there). As I mentioned on the other reply, other 
parts do seem quite generic to me, but let's keep this chunk of the 
discussion on the other thread.

Regarding the breadcrumb code, IMO we do still want to share most of it 
(seqno writing, interrupt, MI_ARB_CHECK, wa_tail), but we most likely 
won't need the preempt_busywait. Given this, it didn't feel right to me 
to move the relevant code out of the file until we get some more mature 
GuC code to make a cleaner call.

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

  reply	other threads:[~2019-12-11 22:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 21:12 [Intel-gfx] [RFC 0/5] Split up intel_lrc.c Daniele Ceraolo Spurio
2019-12-11 21:12 ` [Intel-gfx] [RFC 1/5] drm/i915: introduce logical_ring and lr_context naming Daniele Ceraolo Spurio
2019-12-11 21:20   ` Chris Wilson
2019-12-11 21:33     ` Chris Wilson
2019-12-11 22:04     ` Daniele Ceraolo Spurio
2019-12-11 23:35       ` Matthew Brost
2019-12-11 21:12 ` [Intel-gfx] [RFC 2/5] drm/i915: Move struct intel_virtual_engine to its own header Daniele Ceraolo Spurio
2019-12-11 21:22   ` Chris Wilson
2019-12-11 21:12 ` [Intel-gfx] [RFC 3/5] drm/i915: split out virtual engine code Daniele Ceraolo Spurio
2019-12-11 21:22   ` Chris Wilson
2019-12-11 21:34     ` Daniele Ceraolo Spurio
2019-12-11 23:09       ` Matthew Brost
2019-12-11 21:12 ` [Intel-gfx] [RFC 4/5] drm/i915: move execlists selftests to their own file Daniele Ceraolo Spurio
2019-12-11 21:26   ` Chris Wilson
2019-12-11 22:07     ` Daniele Ceraolo Spurio
2019-12-11 21:12 ` [Intel-gfx] [RFC 5/5] drm/i915: introduce intel_execlists_submission.<c/h> Daniele Ceraolo Spurio
2019-12-11 21:31   ` Chris Wilson
2019-12-11 22:35     ` Daniele Ceraolo Spurio [this message]
2019-12-12  1:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Split up intel_lrc.c Patchwork
2019-12-12  1:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2019-12-12 12:51 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=062ab6cc-ca22-d2cb-7b73-ef5516b04cc3@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox