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 <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx 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 Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
