On 14/06/2019 18:43, Chris Wilson wrote:
Quoting Michal Wajdeczko (2019-06-14 18:18:54)
On Fri, 14 Jun 2019 17:17:01 +0200, Tvrtko Ursulin
<tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
More removal of implicit dev_priv from using old mmio accessors.
Furthermore these calls really operate on ggtt so it logically makes
sense
if they take it as parameter.
Hmm, I'm not sure that we going in right direction here, as these
functions mostly operate on bl_info that today is separate to ggtt.
That was my first thought too, except they are operating inside of ggtt
init/fini.
And it does actually modify ggtt: intel_vgt_balloon -> vgt_balloon_space
-> i915_gem_gtt_reserve.
So to me it sounded passable to make them take ggtt as input parameter.
It is not detrimental if they (the functions) one day decide to wrap
both bl_info and ggtt into a new object.
Sounds passable or objection is hard?
Regards,
Tvrtko
Maybe better option would be to move pure ggtt related functions
vgt_balloon_space/vgt_deballoon_space to i915_gem_ggtt.c|h (after
rename) and allow vgpu functions to keep i915 as parameter ?
Presumably, vgpu would migrate to taking its own object as well. Still
undecided how best to handle ggtt init plugins. My ideal would be that
vgpu init was dynamic and be tuned to work with an existing ggtt, and
never rely on static partitioning.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
