[PATCH 02/11] drm/i915: Avoid forcing relocations through the mappable GTT or CPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2013-01-14 at 21:04 +0100, Daniel Vetter wrote:
> On Mon, Jan 14, 2013 at 8:21 PM, Imre Deak <imre.deak at intel.com> wrote:
> >> +                     drm_clflush_virt_range(vaddr + page_offset, 4);
> >> +                     *(uint32_t *)(vaddr + page_offset) = reloc->delta;
> >> +                     drm_clflush_virt_range(vaddr + page_offset, 4);
> >
> > Discussed this already to some degree with Chris, but I still think the
> > first cache flush is redundant.
> 
> Nope, since it's a partial cacheline write, we need to first flush out
> any stale data, then write the dword (which loads the latest data from
> memory into a cacheline). Then we need to flush the updated cacheline
> out into main memory again. 

Well, the first flush would first write any valid data in the cache line
to memory and only then invalidate it. But this would have the same
result as just doing away with the first flush: the original cache line
updated by the dword.

And if the cache line was invalid the first flush is a no-op and the
write would reload the cache line from memory as you pointed out.

--Imre



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux