On 14/06/2019 10:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-14 10:06:41)
On 13/06/2019 14:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-06-13 14:35:17)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Start using the newly introduced struct intel_gt to fuse together correct
logical init flow with uncore for more removal of implicit dev_priv in
mmio access.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Looks fine, I might move it again later next to the fence registers, or
at least pull this and the detection into its own intel_gt_swizzling.c
Hmm, now that I said that, does that seem like a reasonable thing to do
right away, see i915_gem_fence_regs.c for the swizzle probe?
Is swizzling global for the memory controller or applicable only for
fenced regions?
As far as my understanding goes, it used to be only for fenced regions
when the gpu was the gmch, but completely migrated to the memory
controller around snb (with the ring architecture, the GPU was just
another client). This coincides with swizzling becoming defunct as part
of tiling. To further muddy the pictures, all the time the memory
controller is interleaving across the channels. I am pretty certain
around gen3 this was explicitly controlled by the GPU for its pages, but
by gen5 this is transparent to the GPU. (See the issues with L-shaped
memory configurations where the magic was not hidden from the GPU.)
So, aiui, for our world view tiling and swizzling are complicit.
Hmm.. looking at the code complicit but still seem separate. So I could
be more easily convinced the swizzling code does not actually belong in
i915_gem_fence_reg.c and we should maybe have intel_gt_swizzle.h|c.
However, since it's all already in this file I can move
intel_gt_init_swizzling there as well.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
