We can only assigned random addresses with impunity if we know we have complete control over the ppGTT. If the ppGTT is shared, either aliased with the global GTT or simply the global GTT on ancient HW, then we have to be careful in case they are objects already fixed in place inside the GTT, e.g. active framebuffers. As the relocation code is still available, only enforce no-relocations by default when the context has its own ppGTT. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2491 Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@xxxxxxxxx> --- lib/intel_batchbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c index be764646e..42d7cd251 100644 --- a/lib/intel_batchbuffer.c +++ b/lib/intel_batchbuffer.c @@ -1306,7 +1306,7 @@ __intel_bb_create(int i915, uint32_t size, bool do_relocs) */ struct intel_bb *intel_bb_create(int i915, uint32_t size) { - return __intel_bb_create(i915, size, false); + return __intel_bb_create(i915, size, !gem_uses_full_ppgtt(i915)); } /** -- 2.28.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
