> > +/**
> > + * struct drm_asahi_gem_bind - Arguments passed to
> > + * DRM_IOCTL_ASAHI_GEM_BIND
> > + */
> > +struct drm_asahi_gem_bind {
> > + /** @op: Bind operation (enum drm_asahi_bind_op) */
> > + __u32 op;
> > +
> > + /** @flags: One or more of ASAHI_BIND_* (BIND only) */
> > + __u32 flags;
> > +
> > + /** @handle: GEM object to bind/unbind (BIND or UNBIND_ALL) */
> > + __u32 handle;
> > +
> > + /** @vm_id: The ID of the VM to operate on */
> > + __u32 vm_id;
> > +
> > + /** @offset: Offset into the object (BIND only) */
> > + __u64 offset;
> > +
> > + /**
> > + * @range: Number of bytes to bind/unbind to addr (BIND or UNBIND only)
> > + */
> > + __u64 range;
> > +
> > + /** @addr: Address to bind to (BIND or UNBIND only) */
> > + __u64 addr;
> > +};
>
> No in/out syncobj/fences? This seems to diverge from xe/nouveau/panthor..
Async vm_bind is useful mainly as an optimization, it's not (as far as I
know) required for correctness - you can always wait/signal from a
userspace submit thread with sync vm_bind. It's my understanding (from
when I chatted with Faith about this when bringing up sparse) that this
is how sparse was implemented historically and maybe still is on
Windows?
> > +/**
> > + * enum drm_asahi_sync_type - Sync item type
> > + */
> > +enum drm_asahi_sync_type {
> > + /** @DRM_ASAHI_SYNC_SYNCOBJ: Binary sync object */
> > + DRM_ASAHI_SYNC_SYNCOBJ = 0,
> > +
> > + /** @DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ: Timeline sync object */
> > + DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ = 1,
> > +};
>
> IMHO it would still be worthwhile to also support fence fd's, since it
> would avoid a couple extra ioctls to convert btwn fence fds and
> syncobj for virtgpu native context..
Ditto for this as an optimization. Both of these can be added in a
straightforward backwards-compat way later, so I'm inclined to not add
any extra functionality beyond what we already have (and know works),
rather than commit prematurely to new features and risk getting
something wrong.
(and then it means more rust bindings...)
