Hi Jesse,
On 07/31/2014 07:58 PM, Jesse Barnes wrote:
Expose an ioctl to create Android fences based on the Android sync point
infrastructure (which in turn is based on DMA-buf fences). Just a
sketch at this point, no testing has been done.
There are a couple of goals here:
1) allow applications and libraries to create fences without an
associated buffer
2) re-use a common API so userspace doesn't have to impedance mismatch
between different driver implementations too much
3) allow applications and libraries to use explicit synchronization if
they choose by exposing fences directly
Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
[snip]
+
+/*
+ * i915 fences on sync timelines
+ *
+ * We implement sync points in terms of i915 seqnos. They're exposed
+ * through the new DRM_I915_GEM_FENCE ioctl, and can be mixed and matched
+ * with other Android timelines and aggregated into sync_fences, etc.
+ *
+ * TODO:
+ * rebase on top of Chris's seqno/request stuff and use requests
+ * allow non-RCS fences (need ring/context association)
+ */
+
+struct i915_sync_timeline {
+ struct sync_timeline obj;
+ struct intel_engine_cs *ring;
+ struct drm_i915_private *dev_priv;
+};
+
+struct i915_sync_pt {
+ struct sync_pt pt;
+ u32 seqno;
+};
In case one day more than seqno needs to be exported to userspace,
perhaps it would be handy to version the driver data somehow to allow
for some forward/backward compatibility? Unless kernel/libdrm are
supposed to be updated in lock-step already.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
