On 7/7/23 20:04, Dmitry Osipenko wrote:
> On 7/7/23 18:43, Gurchetan Singh wrote:
>> @@ -161,21 +157,27 @@ static int virtio_gpu_init_submit(struct virtio_gpu_submit *submit,
>> struct drm_file *file,
>> u64 fence_ctx, u32 ring_idx)
>> {
>> + int err;
>> + struct virtio_gpu_fence *out_fence;
>> struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
>> struct virtio_gpu_device *vgdev = dev->dev_private;
>> - struct virtio_gpu_fence *out_fence;
>> - int err;
>> + bool drm_fence_event = (exbuf->flags & VIRTGPU_EXECBUF_RING_IDX) &&
>> + (vfpriv->ring_idx_mask & BIT_ULL(ring_idx));
>
> Previously, when VIRTGPU_EXECBUF_RING_IDX flag wasn't specified, the
> fence event was created for a default ring_idx=0. Now you changed this
> behaviour and event will never be created without
> VIRTGPU_EXECBUF_RING_IDX flag being set.
>
> Could you please point me at the corresponding userspace code that polls
> DRM FD fence event?
>
> It's unclear whether there is a possible userspace regression here or
> not. If there is no regression, then in general such behavioural changes
> should be done in a separate commit having detailed description
> explaining why behaviour changes.
I see that venus does the polling and ring_idx_mask is a
context-specific param, hence it's irrelevant to a generic ctx 0. Still
it's now necessary to specify the EXECBUF_RING_IDX flag even if ctx has
one ring, which is UAPI change.
--
Best regards,
Dmitry
