OK. I see. Previously the fence registers for host is partitioned. For example, host i915 will only take 4 fence registers, others are kept by GVT-g resource allocator for vGPUs. Danile and Kevin, they thought we could use i915 fence stealing functionality to prevent this static partition. So my idea is: a. When GVT create a guest, it will call i915_find_fence_regs for available physical fence registers. b. Then it will call i915_steal_fence and pin these fence registers for vGPUs. c. Then unpin them, when a guest is destroyed. So I expose these two APIs. Do you have any better ideas to share? :) And thanks for the comments. :) -----Original Message----- From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] Sent: Friday, March 11, 2016 8:43 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 14/15] drm/i915: factor out and expose i915_steal_fence() On Fri, Mar 11, 2016 at 12:29:06PM +0000, Wang, Zhi A wrote: > Hi Chris: > Do you mean I should also check the fence pin count in this API like i915_find_fence_reg, then it will be safe here? :) Along those lines. I don't like the prospect of exporting this API and without seeing the consumer I cannot advise on a better method. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
