[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/25 Jerome Glisse <j.glisse at gmail.com>:
> On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae <daeinki at gmail.com> wrote:
>> 2013/6/25 Rob Clark <robdclark at gmail.com>:
>>> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae <daeinki at gmail.com> wrote:
>>>>> that
>>>>> should be the role of kernel memory management which of course needs
>>>>> synchronization btw A and B. But in no case this should be done using
>>>>> dma-buf. dma-buf is for sharing content btw different devices not
>>>>> sharing resources.
>>>>>
>>>>
>>>> hmm, is that true? And are you sure? Then how do you think about
>>>> reservation? the reservation also uses dma-buf with same reason as long
>>>> as I
>>>> know: actually, we use reservation to use dma-buf. As you may know, a
>>>> reservation object is allocated and initialized when a buffer object is
>>>> exported to a dma buf.
>>>
>>> no, this is why the reservation object can be passed in when you
>>> construction the dmabuf.
>>
>> Right, that way, we could use dma buf for buffer synchronization. I
>> just wanted to ask for why Jerome said that "dma-buf is for sharing
>> content btw different devices not sharing resources".
>
> From memory, the motivation of dma-buf was to done for few use case,
> among them webcam capturing frame into a buffer and having gpu using
> it directly without memcpy, or one big gpu rendering a scene into a
> buffer that is then use by low power gpu for display ie it was done to
> allow different device to operate on same data using same backing
> memory.
>
> AFAICT you seem to want to use dma-buf to create scratch buffer, ie a
> process needs to use X amount of memory for an operation, it can
> release|free this memory once its done
> and a process B can the use
> this X memory for its own operation discarding content of process A.
> presume that next frame would have the sequence repeat, process A do
> something, then process B does its thing.
> So to me it sounds like you
> want to implement global scratch buffer using the dmabuf API and that
> sounds bad to me.
>
> I know most closed driver have several pool of memory, long lived
> object, short lived object and scratch space, then user space allocate
> from one of this pool and there is synchronization done by driver
> using driver specific API to reclaim memory.
> Of course this work
> nicely if you only talking about one logic block or at very least hw
> that have one memory controller.
>
> Now if you are thinking of doing scratch buffer for several different
> device and share the memory among then you need to be aware of
> security implication, most obvious being that you don't want process B
> being able to read process A scratch memory.
> I know the argument about
> it being graphic but one day this might become gpu code and it might
> be able to insert jump to malicious gpu code.
>

If you think so, it seems like that there is *definitely* your
misunderstanding. My approach is similar to dma fence: it guarantees
that a DMA cannot access a buffer while other DMA is accessing the
buffer. I guess now some gpu drivers in mainline have been using
specific mechanism for it. And when it comes to the portion you
commented, please know that I just introduced user side mechanism for
buffer sychronization between CPU and CPU, and CPU and DMA in
addition; not implemented but just planned.

Thanks,
Inki Dae

> Cheers,
> Jerome