2013/6/25 Jerome Glisse [off-list ref]:

On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae [off-list ref] wrote:

quoted

2013/6/25 Rob Clark [off-list ref]:

quoted

On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae [off-list ref] wrote:

quoted

quoted

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