Hi, On to, 2016-02-25 at 15:02 +0000, Wang, Zhi A wrote: > > -----Original Message----- > From: Tian, Kevin > Sent: Wednesday, February 24, 2016 4:50 PM > To: Wang, Zhi A; [email protected]; [email protected] > Cc: Lv, Zhiyuan; Niu, Bing; Song, Jike; [email protected]; > Cowperthwaite, David J; [email protected]; > [email protected] > Subject: RE: [RFCv2 10/14] drm/i915: update PDPs by condition when submit the > LRC context > > > > > From: Wang, Zhi A > > Sent: Thursday, February 18, 2016 7:42 PM > > > > Previously the PDPs inside the ring context are updated at: > > > > - When populate a LRC context > > - Before submitting a LRC context (only for 32 bit PPGTT, as the amount > > of used PDPs may change) > > > > This patch postpones the PDPs upgrade to submission time, and will update > > it by condition if the PPGTT is 48b. Under GVT-g, one GVT context will be > > used by different guest, the PPGTT instance related to the context might > > be changed before the submission time. And this patch gives GVT context > > a chance to load the new PPGTT instance into an initialized context. > Could you elaborate why we share one GVT context across different guest? > A natural thought is that we'll create one GVT context per every guest > context... > > [Zhi] We don't have context creation/destroy notification in guest i915 > driver. > Because in our implementation we need an unique context id to anchor the > relationship between shadow context and guest context, while i915 uses GGTT > address as context id. In each context pin/unpin, the context id may be > changes.
Does not this lead to plenty of unnecessary storing and restoring of the context parameters? I would imagine this to destroy performance. Regards, Joonas > > So it's not necessary to allocate multiple GVT context here. > > Thanks > Kevin -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
