Re: [RFC] Add DMA_RESV_USAGE flags

From: "Michel Dänzer" <michel@daenzer.net>
To: Jason Ekstrand <jason@jlekstrand.net>, Daniel Vetter <daniel@ffwll.ch>
Cc: "moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] Add DMA_RESV_USAGE flags
Date: Wed, 19 May 2021 12:52:54 +0200	[thread overview]
Message-ID: <14524566-8854-4bc0-9f70-b7219c9fccfc@daenzer.net> (raw)
In-Reply-To: <CAOFGe97FDc7Y9APymQQZZMApDXsJkbcS0N5jh+3s-w-Ligipug@mail.gmail.com>

On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>>
>> On Tue, May 18, 2021 at 7:40 PM Christian König
>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>> Am 18.05.21 um 18:48 schrieb Daniel Vetter:
>>>> On Tue, May 18, 2021 at 2:49 PM Christian König
>>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>>
>>>>> And as long as we are all inside amdgpu we also don't have any oversync,
>>>>> the issue only happens when we share dma-bufs with i915 (radeon and
>>>>> AFAIK nouveau does the right thing as well).
>>>> Yeah because then you can't use the amdgpu dma_resv model anymore and
>>>> have to use the one atomic helpers use. Which is also the one that
>>>> e.g. Jason is threathening to bake in as uapi with his dma_buf ioctl,
>>>> so as soon as that lands and someone starts using it, something has to
>>>> adapt _anytime_ you have a dma-buf hanging around. Not just when it's
>>>> shared with another device.
>>>
>>> Yeah, and that is exactly the reason why I will NAK this uAPI change.
>>>
>>> This doesn't works for amdgpu at all for the reasons outlined above.
>>
>> Uh that's really not how uapi works. "my driver is right, everyone
>> else is wrong" is not how cross driver contracts are defined. If that
>> means a perf impact until you've fixed your rules, that's on you.
>>
>> Also you're a few years too late with nacking this, it's already uapi
>> in the form of the dma-buf poll() support.
> 
> ^^  My fancy new ioctl doesn't expose anything that isn't already
> there.  It just lets you take a snap-shot of a wait instead of doing
> an active wait which might end up with more fences added depending on
> interrupts and retries.  The dma-buf poll waits on all fences for
> POLLOUT and only the exclusive fence for POLLIN.  It's already uAPI.

Note that the dma-buf poll support could be useful to Wayland compositors for the same purpose as Jason's new ioctl (only using client buffers which have finished drawing for an output frame, to avoid missing a refresh cycle due to client drawing), *if* it didn't work differently with amdgpu.

Am I understanding correctly that Jason's new ioctl would also work differently with amdgpu as things stand currently? If so, that would be a real bummer and might hinder adoption of the ioctl by Wayland compositors.

-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer