On Wed, Jul 01, 2015 at 02:55:47PM +0530, ankitprasad.r.sharma@xxxxxxxxx wrote:
> - ret = i915_gem_shmem_pread(dev, obj, args, file);
> + /* pread for non shmem backed objects */
> + if (!obj->base.filp) {
> + if (obj->tiling_mode == I915_TILING_NONE)
> + ret = i915_gem_gtt_pread_pwrite(dev, obj, args->size,
> + args->offset,
> + args->data_ptr,
> + false);
> + else
> + ret = -EINVAL;
> + } else
> + ret = i915_gem_shmem_pread(dev, obj, args, file);
My preference for structuring this would be to always try the faster
method and move the can-gtt/can-shm tests into that method and then try the
slow path for suitable errno.
That way with the refactoring here, we place all the knowledge of what
objects work with the GTT access inside the GTT accessor. Similarly
wrt to the fast shmem read path.
For extra fun, we can directly read from stolen physical addresses for
gen<6.
Overall the patch lgtm, though I have some cleanups pending to the GTT
access path to handle huge objects - the ordering of those with this
doesn't matter.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
