Quoting Tvrtko Ursulin (2017-09-26 11:30:50)
>
> On 26/09/2017 10:53, Chris Wilson wrote:
> > Take advantage of optimised memset64() instead of open coding it to
> > prefill the GTT pages.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > ---
> > Needs backmerge from 4.14-rc1, but it's tantalisingly close.
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 0477949805e1..74062897d331 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -486,10 +486,8 @@ static void fill_page_dma(struct i915_address_space *vm,
> > const u64 val)
> > {
> > u64 * const vaddr = kmap_atomic(p->page);
> > - int i;
> >
> > - for (i = 0; i < 512; i++)
> > - vaddr[i] = val;
> > + memset64(vaddr, val, PAGE_SIZE / sizeof(val));
> >
> > kunmap_atomic(vaddr);
> > }
> >
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
>
> I wonder if for 32-bit builds (who cares) memset32 would be better in
> fill_page_dma_32 or it makes no difference?
I considered it, but I thought the unification would still be to our
advantage, and even then that arch may still have a fancy memset64?
One day, we should build a 32bit bdw/skl just for fun and see if
profiles any differently. As well as fixing all the u32/u64 bugs.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
