op 05-08-14 16:59, Jesse Barnes schreef:
> On Tue, 5 Aug 2014 09:44:00 +0200
> Daniel Vetter <daniel@xxxxxxxx> wrote:
>
>> On Tue, Aug 5, 2014 at 1:18 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
>>> +#define DRM_IOCTL_I915_GEM_FENCE DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_FENCE, struct drm_i915_gem_fence)
>>>
>>> /* Allow drivers to submit batchbuffers directly to hardware, relying
>>> * on the security mechanisms provided by hardware.
>>> @@ -1066,4 +1068,25 @@ struct drm_i915_gem_userptr {
>>> __u32 handle;
>>> };
>>>
>>> +/**
>>> + * drm_i915_gem_fence - create a fence
>>> + * @fd: fd for fence
>>> + * @ctx_id: context ID for fence
>>> + * @flags: flags for operation
>>> + *
>>> + * Creates a fence in @fd and returns it to the caller. This fd can be
>>> + * passed around between processes as any other fd, and can be poll'd
>>> + * and read for status.
>>> + *
>>> + * RETURNS:
>>> + * A valid fd in the @fd field or an errno on error.
>>> + */
>>> +struct drm_i915_gem_fence {
>>> + __s32 fd;
>>> + __u32 ctx_id;
>>> + __u32 flags;
>>> + __u32 pad;
>>> + char name[32];
>>> +};
>>> +
>> This doesn't really look like the interface I'd expected. Imo we just
>> need to add a flag to execbuf so that userspace can tell the kernel to
>> create a fence for that execbuf, and switch one of the leftover rsvd
>> fields to __s32 as an outparam for the fd.
> Given that I've got a new execbuf coming too, I just wanted to keep
> them separate. Any compelling reason to try to wedge it into execbuf?
It's the right place to put it, and you can get the fence for nearly free because you just created it.
~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
