On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> @@ -871,7 +845,7 @@ shmem_clflush_swizzled_range(char *addr, unsigned long length,
> /* Only difference to the fast-path function is that this can handle bit17
> * and uses non-atomic copy and kmap functions. */
> static int
> -shmem_pread_slow(struct page *page, int shmem_page_offset, int page_length,
> +shmem_pread_slow(struct page *page, int offset, int length,
Lets maybe call this shmem_pread_cpu? I understand it's been faster on
recent generations even for swizzling. Can be added as follow-up.
> +static int
> +i915_gem_shmem_pread(struct drm_i915_gem_object *obj,
> + struct drm_i915_gem_pread *args)
> +{
> + char __user *user_data;
> + u64 remain;
> + unsigned int obj_do_bit17_swizzling;
> + unsigned int needs_clflush;
> + unsigned int idx, offset;
> + int ret;
> +
> + obj_do_bit17_swizzling = 0;
> + if (i915_gem_object_needs_bit17_swizzle(obj))
> + obj_do_bit17_swizzling = 1 << 17;
Could use BIT(17) to make it super explicit.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Regards, Joonas
PS. Something like C context-aware diff would be super, would make
reading these much more fun. Or maybe patchwork 2-way diff view.
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
