On Tue, 10 Jul 2012 11:21:57 +0200, Daniel Vetter <daniel at ffwll.ch> wrote: > On Mon, Jul 09, 2012 at 12:34:37PM +0100, Chris Wilson wrote: > > In order to support snoopable memory on non-LLC architectures (so that > > we can bind vgem objects into the i915 GATT for example), we have to > > avoid the prefetcher on the GPU from crossing memory domains and so > > prevent allocation of a snoopable PTE immediately following an uncached > > PTE. To do that, we need to extend the range allocator with support for > > tracking and segregating different node colours. > > > > This will be used by i915 to segregate memory domains within the GTT. > > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> > > Cc: Dave Airlie <airlied at redhat.com > > Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> > > Cc: Ben Skeggs <bskeggs at redhat.com> > > Cc: Jerome Glisse <jglisse at redhat.com> > > Cc: Alex Deucher <alexander.deucher at amd.com> > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch> > > Two little bikesheds: > - Do we really need 64bits of colour? Especially since we have quite a few > bits of space left ... It was following the convention that we passed around an argument large enough to stuff a pointer into if we ever needed to make a far more complex decision. > - I think we could add a new insert_color helper that always takes a range > (we can select the right rang in the driver). That way this patch > wouldn't need to touch the drivers, and we could take the opportunity to > embed the gtt_space mm_node into our gem object ... I was just a bit more wary of adding yet another helper since they quickly get just as confusing as the extra arguments they replace. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre
