>-----Original Message----- >From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] >Sent: Friday, June 22, 2018 3:37 PM >To: Zhao, Yakui <yakui.zhao@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx >Subject: RE: [PATCH V2] drm/i915: Use I915_MAP_WC for execlists context >buffer on the platforms without LLC > >Quoting Zhao, Yakui (2018-06-22 08:29:15) >> >> >> >-----Original Message----- >> >From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] >> >Sent: Friday, June 22, 2018 2:36 PM >> >To: Zhao, Yakui <yakui.zhao@xxxxxxxxx>; >> >intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> >Cc: Zhao, Yakui <yakui.zhao@xxxxxxxxx> >> >Subject: Re: [PATCH V2] drm/i915: Use I915_MAP_WC for execlists >> >context buffer on the platforms without LLC >> > >> >Quoting Zhao Yakui (2018-06-22 07:09:10) >> >> @@ -2728,6 +2729,7 @@ populate_lr_context(struct i915_gem_context >*ctx, >> >> struct intel_engine_cs *engine, >> >> struct intel_ring *ring) { >> >> + enum i915_map_type map = HAS_LLC(ctx->i915) ? I915_MAP_WB : >> >> + I915_MAP_WC; >> >> void *vaddr; >> >> u32 *regs; >> >> int ret; >> >> @@ -2738,13 +2740,12 @@ populate_lr_context(struct >i915_gem_context >> >*ctx, >> >> return ret; >> >> } >> >> >> >> - vaddr = i915_gem_object_pin_map(ctx_obj, I915_MAP_WB); >> >> + vaddr = i915_gem_object_pin_map(ctx_obj, map); >> > >> >As this uses the cpu domain and flushed afterwards, this one is >> >correct in its usage of MAP_WB. >> >> In this function the content of context state is flushed. >> >> But the function of execlists_submit_ports will update it again before writing >the ELSP port. >> And there is no flush. In fact after the ELSP port is written, the HW will start >to execute the submitted commands. > >That's a different map. Really? It is allocated in one gem obj. Will you please help to point out where to handle the different map? Thanks Yakui >-Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
