Hi Chris:
Your idea is good. :) We could emit PDP upgrade LRIs like i915
before emit GVT worload under GVT context, then we can reuse the
pd_dirty_ring bitmap.
But I have to expose intel_logical_ring_emit_pdps() function for GVT-g.
Is it acceptable?
Thanks,
Zhi.
On 03/11/16 20:56, Wang, Zhi A wrote:
OK. I will see. :) Thanks for the comments.
-----Original Message-----
From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx]
Sent: Friday, March 11, 2016 7:28 PM
To: Wang, Zhi A
Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; igvt-g@xxxxxxxxxxxx; Tian, Kevin; Lv, Zhiyuan; Niu, Bing; Song, Jike; daniel.vetter@xxxxxxxx; Cowperthwaite, David J; joonas.lahtinen@xxxxxxxxxxxxxxx
Subject: Re: [RFCv3 10/15] drm/i915: update PDPs by condition when submit the LRC context
On Fri, Mar 11, 2016 at 06:59:41PM +0800, Zhi Wang wrote:
Previously the PDPs inside the ring context will be updated
- When populating a LRC context
- Before submitting a LRC context (only for 32 bit PPGTT, as the amount
of used PDPs may be changed during PPGTT page table grow)
Under GVT-g, each VM owns a GVT context used as the shadow context. When
guest submits a context, GVT-g will load guest context into the GVT
context, and submit this context to i915 GEM submission system.
So this GVT context could be used by different guest context, and the
PPGTT root pointer in guest contexts might be different as well, if guest
is using full PPGTT mode.
In current i915, the root pointer in a LRC context will only be updated
during the LRC context creation.
This patch postpones the root pointer upgrade to the time of submission,
which will give GVT-g a chance to reload a new PPGTT page table root
pointer into an existing GVT context.
Not explained is why you cannot use the existing dirty flags.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
