Re: [PATCH 1/4] drm/i915: Clearing buffer objects via blitter engine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 01, 2015 at 03:54:55PM +0100, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 07/01/2015 10:25 AM, ankitprasad.r.sharma@xxxxxxxxx wrote:
> >From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx>
> >
> >This patch adds support for clearing buffer objects via blitter
> >engines. This is particularly useful for clearing out the memory
> >from stolen region.
> 
> Because CPU cannot access it? I would put that into the commit
> message since I think cover letter does not go into the git history.
> 
> >v2: Add support for using execlists & PPGTT
> >
> >v3: Fix issues in legacy ringbuffer submission mode
> >
> >v4: Rebased to the latest drm-intel-nightly (Ankit)
> >
> >testcase: igt/gem_stolen
> >
> 
> Nitpick: usually it is "Testcase:" and all tags grouped together.
> 
> >Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >Signed-off-by: Deepak S <deepak.s at linux.intel.com>
> >Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> >---
> >  drivers/gpu/drm/i915/Makefile           |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h         |   4 +
> >  drivers/gpu/drm/i915/i915_gem_exec.c    | 201 ++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/intel_lrc.c        |   4 +-
> >  drivers/gpu/drm/i915/intel_lrc.h        |   3 +
> >  drivers/gpu/drm/i915/intel_ringbuffer.c |   2 +-
> >  drivers/gpu/drm/i915/intel_ringbuffer.h |   1 +
> >  7 files changed, 213 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/gpu/drm/i915/i915_gem_exec.c
> >
> >diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> >index de21965..1959314 100644
> >--- a/drivers/gpu/drm/i915/Makefile
> >+++ b/drivers/gpu/drm/i915/Makefile
> >@@ -24,6 +24,7 @@ i915-y += i915_cmd_parser.o \
> >  	  i915_gem_debug.o \
> >  	  i915_gem_dmabuf.o \
> >  	  i915_gem_evict.o \
> >+	  i915_gem_exec.o \
> >  	  i915_gem_execbuffer.o \
> >  	  i915_gem_gtt.o \
> >  	  i915_gem.o \
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >index ea9caf2..d1e151e 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -3082,6 +3082,10 @@ int __must_check i915_gem_evict_something(struct drm_device *dev,
> >  int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
> >  int i915_gem_evict_everything(struct drm_device *dev);
> >
> >+/* i915_gem_exec.c */
> >+int i915_gem_exec_clear_object(struct drm_i915_gem_object *obj,
> >+			       struct drm_i915_file_private *file_priv);
> >+
> >  /* belongs in i915_gem_gtt.h */
> >  static inline void i915_gem_chipset_flush(struct drm_device *dev)
> >  {
> >diff --git a/drivers/gpu/drm/i915/i915_gem_exec.c b/drivers/gpu/drm/i915/i915_gem_exec.c
> >new file mode 100644
> >index 0000000..a07fda0
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/i915_gem_exec.c
> >@@ -0,0 +1,201 @@
> >+/*
> >+ * Copyright © 2013 Intel Corporation
> 
> Is the year correct?

Yes, but it should be extended to include the lrc mess.
 
> >+ *
> >+ * Permission is hereby granted, free of charge, to any person obtaining a
> >+ * copy of this software and associated documentation files (the "Software"),
> >+ * to deal in the Software without restriction, including without limitation
> >+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> >+ * and/or sell copies of the Software, and to permit persons to whom the
> >+ * Software is furnished to do so, subject to the following conditions:
> >+ *
> >+ * The above copyright notice and this permission notice (including the next
> >+ * paragraph) shall be included in all copies or substantial portions of the
> >+ * Software.
> >+ *
> >+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> >+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> >+ * IN THE SOFTWARE.
> >+ *
> >+ * Authors:
> >+ *    Chris Wilson <chris at chris-wilson.co.uk>
> 
> And author?

Yes. If we discount the ugly changes to support two parallel ring
interface api's that are doing identical jobs.
 
> >+ *
> >+ */
> >+
> >+#include <drm/drmP.h>
> >+#include <drm/i915_drm.h>
> >+#include "i915_drv.h"
> >+
> >+#define GEN8_COLOR_BLT_CMD (2<<29 | 0x50<<22)
> >+
> >+#define BPP_8 0
> >+#define BPP_16 (1<<24)
> >+#define BPP_32 (1<<25 | 1<<24)
> >+
> >+#define ROP_FILL_COPY (0xf0 << 16)
> >+
> >+static int i915_gem_exec_flush_object(struct drm_i915_gem_object *obj,
> >+				      struct intel_engine_cs *ring,
> >+				      struct intel_context *ctx,
> >+				      struct drm_i915_gem_request **req)
> >+{
> >+	int ret;
> >+
> >+	ret = i915_gem_object_sync(obj, ring, req);
> >+	if (ret)
> >+		return ret;
> >+
> >+	if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
> >+		if (i915_gem_clflush_object(obj, false))
> >+			i915_gem_chipset_flush(obj->base.dev);
> >+		obj->base.write_domain &= ~I915_GEM_DOMAIN_CPU;
> >+	}
> >+	if (obj->base.write_domain & I915_GEM_DOMAIN_GTT) {
> >+		wmb();
> >+		obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
> >+	}
> 
> All this could be replaced with i915_gem_object_set_to_gtt_domain, no?

No. Technically this is i915_gem_execbuffer_move_to_gpu().

> >+
> >+	return i915.enable_execlists ?
> >+			logical_ring_invalidate_all_caches(*req) :
> >+			intel_ring_invalidate_all_caches(*req);
> 
> And this is done on actual submission for you by the lower levels so
> you don't need to call it directly.

What submission? We don't build a batch, we are building a raw request
to do the operation from the ring.

> >+}
> >+
> >+static void i915_gem_exec_dirty_object(struct drm_i915_gem_object *obj,
> >+				       struct intel_engine_cs *ring,
> >+				       struct i915_address_space *vm,
> >+				       struct drm_i915_gem_request *req)
> >+{
> >+	i915_gem_request_assign(&obj->last_write_req, req);
> >+	obj->base.read_domains = I915_GEM_DOMAIN_RENDER;
> >+	obj->base.write_domain = I915_GEM_DOMAIN_RENDER;
> >+	i915_vma_move_to_active(i915_gem_obj_to_vma(obj, vm), req);
> >+	obj->dirty = 1;
> >+
> >+	ring->gpu_caches_dirty = true;
> >+}
> >+
> >+int i915_gem_exec_clear_object(struct drm_i915_gem_object *obj,
> >+			       struct drm_i915_file_private *file_priv)
> >+{
> 
> Function needs some good kerneldoc.
> 
> >+	struct drm_device *dev = obj->base.dev;
> >+	struct drm_i915_private *dev_priv = dev->dev_private;
> >+	struct intel_engine_cs *ring;
> >+	struct intel_context *ctx;
> >+	struct intel_ringbuffer *ringbuf;
> >+	struct i915_address_space *vm;
> >+	struct drm_i915_gem_request *req;
> >+	int ret = 0;
> >+
> >+	lockdep_assert_held(&dev->struct_mutex);
> 
> It think there was some guidance that lockdep_assert_held is
> compiled out when lockdep is not in the kernel and that WARN_ON is
> preferred. In this case that would probably be WARN_ON_ONCE and
> return error.

Hah, this predates that and I still disagree.
 
> >+	ring = &dev_priv->ring[HAS_BLT(dev) ? BCS : RCS];
> >+	ctx = i915_gem_context_get(file_priv, DEFAULT_CONTEXT_HANDLE);
> >+	/* Allocate a request for this operation nice and early. */
> >+	ret = i915_gem_request_alloc(ring, ctx, &req);
> >+	if (ret)
> >+		return ret;
> >+
> >+	if (ctx->ppgtt)
> >+		vm = &ctx->ppgtt->base;
> >+	else
> >+		vm = &dev_priv->gtt.base;
> >+
> >+	if (i915.enable_execlists && !ctx->engine[ring->id].state) {
> >+		ret = intel_lr_context_deferred_create(ctx, ring);
> 
> i915_gem_context_get above and this call are very similar to what
> i915_gem_validate_context does. It seems to me it would be better to
> call the latter function here.

No, the intel_lrc API is absolute garbage and needs to be taken out the
back and shot. Until that is done, I wouldn't bother continuing to try
and use the interface at all.

All that needs to happen here is:

req = i915_gem_request_alloc(ring, ring->default_context);

and for the request/lrc to go off and dtrt.

> >+	}
> >+
> >+	ringbuf = ctx->engine[ring->id].ringbuf;
> >+
> >+	ret = i915_gem_object_pin(obj, vm, PAGE_SIZE, 0);
> >+	if (ret)
> >+		return ret;
> >+
> >+	if (obj->tiling_mode && INTEL_INFO(dev)->gen <= 3) {
> >+		ret = i915_gem_object_put_fence(obj);
> >+		if (ret)
> >+			goto unpin;
> >+	}
> 
> Why is this needed?

Because it's a requirement of the op being used on those gen. Later gen
can keep the fence.
 
> Could it be called unconditionally and still work?
> 
> At least I would recommend a comment explaining it.
> 
> >+	ret = i915_gem_exec_flush_object(obj, ring, ctx, &req);
> >+	if (ret)
> >+		goto unpin;
> 
> As I said above one call to i915_gem_object_set_to_gtt_domain would
> be enough I think.

But wrong ;-)
 
> >+	if (i915.enable_execlists) {
> >+		if (dev_priv->info.gen >= 8) {
> >+			ret = intel_logical_ring_begin(req, 8);
> >+			if (ret)
> >+				goto unpin;
> >+
> >+			intel_logical_ring_emit(ringbuf, GEN8_COLOR_BLT_CMD |
> >+							 BLT_WRITE_RGBA |
> >+							 (7-2));
> >+			intel_logical_ring_emit(ringbuf, BPP_32 |
> >+							 ROP_FILL_COPY |
> >+							 PAGE_SIZE);
> >+			intel_logical_ring_emit(ringbuf, 0);
> >+			intel_logical_ring_emit(ringbuf,
> >+						obj->base.size >> PAGE_SHIFT
> >+						<< 16 | PAGE_SIZE / 4);
> >+			intel_logical_ring_emit(ringbuf,
> >+						i915_gem_obj_offset(obj, vm));
> >+			intel_logical_ring_emit(ringbuf, 0);
> >+			intel_logical_ring_emit(ringbuf, 0);
> >+			intel_logical_ring_emit(ringbuf, MI_NOOP);
> >+
> >+			intel_logical_ring_advance(ringbuf);
> >+		} else {
> >+			DRM_ERROR("Execlists not supported for gen %d\n",
> >+				  dev_priv->info.gen);
> >+			ret = -EINVAL;
> 
> I would put a WARN_ON_ONCE here, or even just return -EINVAL. If the
> driver is so messed up in general that execlists are enabled < gen8
> I think there is no point logging errors about it from here. Would
> also save you one indentation level.

I would just rewrite this to have a logical interface to the rings. Oh
wait, I did.

> >+		__intel_ring_advance(ring);
> >+	}
> >+
> >+	i915_gem_exec_dirty_object(obj, ring, vm, req);
> 
> Where is this request actually submitted?

True, that's a rebase error.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux