Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Add per context timelines to fence object
Op 22-02-16 om 15:33 schreef John Harrison: > On 18/02/2016 14:49, Chris Wilson wrote: >> On Thu, Feb 18, 2016 at 02:24:06PM +, john.c.harri...@intel.com wrote: >>> From: John Harrison >>> >>> The fence object used inside the request structure requires a sequence >>> number. Although this is not used by the i915 driver itself, it could >>> potentially be used by non-i915 code if the fence is passed outside of >>> the driver. This is the intention as it allows external kernel drivers >>> and user applications to wait on batch buffer completion >>> asynchronously via the dma-buff fence API. >>> >>> To ensure that such external users are not confused by strange things >>> happening with the seqno, this patch adds in a per context timeline >>> that can provide a guaranteed in-order seqno value for the fence. This >>> is safe because the scheduler will not re-order batch buffers within a >>> context - they are considered to be mutually dependent. >> This is still nonsense. Just implement per-context seqno. > If you already have a set of patches to implement per-context seqno then > let's get them merged. Otherwise, that is follow up work to be done once the > scheduler has landed. There has already been too much churn and delay. So the > decision is to get the scheduler in as soon as possible and any 'could do > better' issues should be logged for follow up work. Seems to me that per context seqno would be cleaner than this hack.. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Add per context timelines to fence object
On 18/02/2016 14:49, Chris Wilson wrote: On Thu, Feb 18, 2016 at 02:24:06PM +, john.c.harri...@intel.com wrote: From: John Harrison The fence object used inside the request structure requires a sequence number. Although this is not used by the i915 driver itself, it could potentially be used by non-i915 code if the fence is passed outside of the driver. This is the intention as it allows external kernel drivers and user applications to wait on batch buffer completion asynchronously via the dma-buff fence API. To ensure that such external users are not confused by strange things happening with the seqno, this patch adds in a per context timeline that can provide a guaranteed in-order seqno value for the fence. This is safe because the scheduler will not re-order batch buffers within a context - they are considered to be mutually dependent. This is still nonsense. Just implement per-context seqno. If you already have a set of patches to implement per-context seqno then let's get them merged. Otherwise, that is follow up work to be done once the scheduler has landed. There has already been too much churn and delay. So the decision is to get the scheduler in as soon as possible and any 'could do better' issues should be logged for follow up work. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Add per context timelines to fence object
On Thu, Feb 18, 2016 at 02:24:06PM +, john.c.harri...@intel.com wrote: > From: John Harrison > > The fence object used inside the request structure requires a sequence > number. Although this is not used by the i915 driver itself, it could > potentially be used by non-i915 code if the fence is passed outside of > the driver. This is the intention as it allows external kernel drivers > and user applications to wait on batch buffer completion > asynchronously via the dma-buff fence API. > > To ensure that such external users are not confused by strange things > happening with the seqno, this patch adds in a per context timeline > that can provide a guaranteed in-order seqno value for the fence. This > is safe because the scheduler will not re-order batch buffers within a > context - they are considered to be mutually dependent. This is still nonsense. Just implement per-context seqno. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/7] drm/i915: Add per context timelines to fence object
From: John Harrison
The fence object used inside the request structure requires a sequence
number. Although this is not used by the i915 driver itself, it could
potentially be used by non-i915 code if the fence is passed outside of
the driver. This is the intention as it allows external kernel drivers
and user applications to wait on batch buffer completion
asynchronously via the dma-buff fence API.
To ensure that such external users are not confused by strange things
happening with the seqno, this patch adds in a per context timeline
that can provide a guaranteed in-order seqno value for the fence. This
is safe because the scheduler will not re-order batch buffers within a
context - they are considered to be mutually dependent.
v2: New patch in series.
v3: Renamed/retyped timeline structure fields after review comments by
Tvrtko Ursulin.
Added context information to the timeline's name string for better
identification in debugfs output.
v5: Line wrapping and other white space fixes to keep style checker
happy.
For: VIZ-5190
Signed-off-by: John Harrison
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 25 +++---
drivers/gpu/drm/i915/i915_gem.c | 83 +
drivers/gpu/drm/i915/i915_gem_context.c | 16 ++-
drivers/gpu/drm/i915/intel_lrc.c| 8
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
5 files changed, 115 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 86ef0b4..62dbdf2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -845,6 +845,15 @@ struct i915_ctx_hang_stats {
bool banned;
};
+struct i915_fence_timeline {
+ charname[32];
+ unsignedfence_context;
+ unsignednext;
+
+ struct intel_context *ctx;
+ struct intel_engine_cs *ring;
+};
+
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
@@ -892,6 +901,7 @@ struct intel_context {
struct i915_vma *lrc_vma;
u64 lrc_desc;
uint32_t *lrc_reg_state;
+ struct i915_fence_timeline fence_timeline;
} engine[I915_NUM_RINGS];
struct list_head link;
@@ -2200,13 +2210,10 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
struct drm_i915_gem_request {
/**
* Underlying object for implementing the signal/wait stuff.
-* NB: Never call fence_later() or return this fence object to user
-* land! Due to lazy allocation, scheduler re-ordering, pre-emption,
-* etc., there is no guarantee at all about the validity or
-* sequentiality of the fence's seqno! It is also unsafe to let
-* anything outside of the i915 driver get hold of the fence object
-* as the clean up when decrementing the reference count requires
-* holding the driver mutex lock.
+* NB: Never return this fence object to user land! It is unsafe to
+* let anything outside of the i915 driver get hold of the fence
+* object as the clean up when decrementing the reference count
+* requires holding the driver mutex lock.
*/
struct fence fence;
@@ -2295,6 +2302,10 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct drm_i915_gem_request **req_out);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
+int i915_create_fence_timeline(struct drm_device *dev,
+ struct intel_context *ctx,
+ struct intel_engine_cs *ring);
+
static inline bool i915_gem_request_completed(struct drm_i915_gem_request *req)
{
return fence_is_signaled(&req->fence);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e170732..2d50287 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2731,9 +2731,35 @@ static const char
*i915_gem_request_get_driver_name(struct fence *req_fence)
static const char *i915_gem_request_get_timeline_name(struct fence *req_fence)
{
- struct drm_i915_gem_request *req = container_of(req_fence,
-typeof(*req), fence);
- return req->ring->name;
+ struct drm_i915_gem_request *req;
+ struct i915_fence_timeline *timeline;
+
+ req = container_of(req_fence, typeof(*req), fence);
+ timeline = &req->ctx->engine[req->ring->id].fence_timeline;
+
+ return timeline->name;
+}
+
+static void i915_gem_request_timeline_value_str(struct fence *req_fence,
+ char *str, int size)
+{
+ struct drm_i915_gem_request *req;
+
+ req = container_of(req_fence, typeof(*req), fence);
+
+ /* Last signalled timeline value ??? */
+ snprintf(str, size, "? [%d]"/*, timeline->value*/,
+req->r
