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
next prev parent 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