[PATCH v4 3/4] drm/virtio: add in/out fence support for explicit synchronization

Robert Foss robert.foss at collabora.com
Mon Nov 12 12:05:47 UTC 2018



On 2018-11-12 12:11, Gerd Hoffmann wrote:
> On Mon, Nov 12, 2018 at 11:30:57AM +0100, Robert Foss wrote:
>> Hey Gerd
>>
>> On 2018-11-12 10:10, Gerd Hoffmann wrote:
>>> On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote:
>>>> Hey Gerd,
>>>>
>>>> On 2018-11-09 11:13, Gerd Hoffmann wrote:
>>>>> On Mon, Nov 05, 2018 at 05:25:05PM +0000, Emil Velikov wrote:
>>>>>> On Mon, 5 Nov 2018 at 11:42, Robert Foss <robert.foss at collabora.com> wrote:
>>>>>>>
>>>>>>> When the execbuf call receives an in-fence it will get the dma_fence
>>>>>>> related to that fence fd and wait on it before submitting the draw call.
>>>>>>>
>>>>>>> On the out-fence side we get fence returned by the submitted draw call
>>>>>>> and attach it to a sync_file and send the sync_file fd to userspace. On
>>>>>>> error -1 is returned to userspace.
>>>>>>>
>>>>>>> Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.com>
>>>>>>> Signed-off-by: Robert Foss <robert.foss at collabora.com>
>>>>>>> Suggested-by: Rob Herring <robh at kernel.org>
>>>>>>> Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Changes since v3:
>>>>>>>     - Move all in_fence handling to the same VIRTGPU_EXECBUF_FENCE_FD_IN block
>>>>>> Fwiw my suggestion was to explicitly document whether the IOCTL can
>>>>>> support, simultaneously, IN and OUT fence.
>>>>>
>>>>> Yes, that would be good.  Code looks like it is supposed to work, but
>>>>> explicitly saying so in the commit message would be nice.
>>>>
>>>> On it! Will send out a v5.
>>>>
>>>>>
>>>>> Also: should we use separate fields for in/out fds?
>>>>
>>>> I'm not sure I understand which fields you're referring to.
>>>
>>> fence_in_fd & fence_out_fd in the ioctl struct (patch #2).
>>
>> I had a look into this and how other drivers are doing it.
>> msm[1] and etnaviv[2] seem to use the same dual-use variable.
> 
> Ok, lets do it the same way then.
> What is the status of the userspace side of this?

The patch is hosted here[1], but is as of yet unmerged.

I know the drm subsystem requires a userspace implementation of
all features, but does it have to be upstreamed first?

[1] https://gitlab.collabora.com/robertfoss/mesa/commits/virtio_fences_v3


Rob.


More information about the dri-devel mailing list