On Sun, Jul 21, 2013 at 03:01:32PM +0200, Daniel Vetter wrote:
> On Sun, Jul 21, 2013 at 01:49:16PM +0100, Chris Wilson wrote:
> > This reverts commit e3dff585508636c8d2915cc1595e04f16ccd66ba.
> > 
> > The bspec recommends that this only be setup as part of the context for
> > GPGPU as it penalizes 3D workloads. As we have exactly zero GPGPU
> > clients at present, optimizing for them makes no sense.
> > 
> > The description from the bspec on how the driver should setup the memory
> > hints is as follows:
> >   "As part of the memory interface programming another option is to
> >   re-allocate TLBs between different streams of GFX. The GFX TLBs are
> >   organized as assigned resources for dedicated ports which could be
> >   re-programmed based on the context that is being executed. This is
> >   especially critical for the L3 backed clients which are seeing one large
> >   TLB. The default programming favors 3D workloads (384 entry for
> >   Textures, 64 entry for data port, 64 entry for rest), however for GPGPU
> >   recommended setting is (64 for textures, 384 for dataport, 64 for rest).
> >   With this new setting there are certain GPGPU workloads which benefit
> >   significantly. Driver needs to make this setting part of the context
> >   that is submitted. "
> > 
> > Signed-off-by: Chris Wilson <[email protected]>
> > Cc: Ben Widawsky <[email protected]>
> 
> Cc: [email protected]

Yikes, just read the w/a db. Apparently the w/a is required because the
hw has the sense of this bit reversed. That is we need to set the bit
for 3d, and clear it for GPGPU.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to