From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH 1/3] drm: Add colouring to the range
	allocator
Date: Tue, 10 Jul 2012 10:29:09 +0100
Message-ID: <1341912549_237368@CP5-2952>
References: <1341833679-11614-1-git-send-email-chris@chris-wilson.co.uk>
	<1341833679-11614-2-git-send-email-chris@chris-wilson.co.uk>
	<20120710092157.GB5108@phenom.ffwll.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236])
	by gabe.freedesktop.org (Postfix) with ESMTP id 1F3949E930
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 10 Jul 2012 02:29:25 -0700 (PDT)
In-Reply-To: <20120710092157.GB5108@phenom.ffwll.local>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>, intel-gfx@lists.freedesktop.org, Jerome Glisse <jglisse@redhat.com>, Ben Skeggs <bskeggs@redhat.com>, Daniel Vetter <daniel.vetter@ffwll.ch>, Alex Deucher <alexander.deucher@amd.com>
List-Id: intel-gfx@lists.freedesktop.org

On Tue, 10 Jul 2012 11:21:57 +0200, Daniel Vetter <daniel@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@chris-wilson.co.uk>
> > Cc: Dave Airlie <airlied@redhat.com
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: Jerome Glisse <jglisse@redhat.com>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Daniel Vetter <daniel.vetter@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