From: Zhenyu Wang <zhenyuw@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 02/10] drm/i915/gvt: Pin the per-engine GVT shadow contexts
Date: Fri, 26 Apr 2019 11:30:54 +0800 [thread overview]
Message-ID: <20190426033054.GE17995@zhen-hp.sh.intel.com> (raw)
In-Reply-To: <155620942405.3869.12593455008445823620@skylake-alporthouse-com>
[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]
On 2019.04.25 17:23:44 +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-04-25 06:42:02)
> > Our eventual goal is to rid request construction of struct_mutex, with
> > the short term step of lifting the struct_mutex requirements into the
> > higher levels (i.e. the caller must ensure that the context is already
> > pinned into the GTT). In this patch, we pin GVT's shadow context upon
> > allocation and so keep them pinned into the GGTT for as long as the
> > virtual machine is alive, and so we can use the simpler request
> > construction path safe in the knowledge that the hard work is already
> > done.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
>
> Hi Zhenyu, could you check through this patch and make sure I haven't
> broken gvt in the process?
>
> The end result is that the gvt shadow context is always pinned into the
> ggtt, avoids any eviction/shrinking, and so allows gvt to use the faster
> paths for request allocation.
yeah, the change looks sane to me. I still like to run some regression test
on this before merging, will reply result to you.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-04-26 3:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 5:42 [PATCH 01/10] drm/i915: Seal races between async GPU cancellation, retirement and signaling Chris Wilson
2019-04-25 5:42 ` [PATCH 02/10] drm/i915/gvt: Pin the per-engine GVT shadow contexts Chris Wilson
2019-04-25 16:23 ` Chris Wilson
2019-04-26 3:30 ` Zhenyu Wang [this message]
2019-04-26 6:04 ` Zhenyu Wang
2019-04-26 6:17 ` Chris Wilson
2019-04-25 5:42 ` [PATCH 03/10] drm/i915: Export intel_context_instance() Chris Wilson
2019-04-25 5:42 ` [PATCH 04/10] drm/i915/selftests: Use the real kernel context for sseu isolation tests Chris Wilson
2019-04-25 5:42 ` [PATCH 05/10] drm/i915/selftests: Pass around intel_context for sseu Chris Wilson
2019-04-25 5:42 ` [PATCH 06/10] drm/i915: Pass intel_context to intel_context_pin_lock() Chris Wilson
2019-04-25 5:42 ` [PATCH 07/10] drm/i915: Split engine setup/init into two phases Chris Wilson
2019-04-25 5:42 ` [PATCH 08/10] drm/i915: Switch back to an array of logical per-engine HW contexts Chris Wilson
2019-04-25 5:42 ` [PATCH 09/10] drm/i915: Remove intel_context.active_link Chris Wilson
2019-04-25 5:42 ` [PATCH 10/10] drm/i915: Move i915_request_alloc into selftests/ Chris Wilson
2019-04-25 6:58 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915: Seal races between async GPU cancellation, retirement and signaling Patchwork
2019-04-25 7:03 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-25 7:29 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-04-26 6:12 ` ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915: Seal races between async GPU cancellation, retirement and signaling (rev2) 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=20190426033054.GE17995@zhen-hp.sh.intel.com \
--to=zhenyuw@linux.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 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.