[PATCH v3] drm/virtio: conditionally allocate virtio_gpu_fence

[Dmitry Osipenko]

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