From: Russell King - ARM Linux <hidden> Date: 2013-06-19 18:33:21
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object. And
the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt handler):
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma access
as long as possible.
What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
-----Original Message-----
From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
Behalf Of Russell King - ARM Linux
Sent: Thursday, June 20, 2013 3:29 AM
To: Inki Dae
Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
Cho; linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
quoted
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object.
And
quoted
the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt
handler):
quoted
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma
access
quoted
as long as possible.
What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
I didn't explain that enough. Sorry about that. 'nothing to do' means that a
dmabuf sync interface isn't called but existing functions are called. So
this may be explained again:
ioctl(dqbuf command)
|
|
dqbuf <- 1. dma_unmap_sg
2. dma_buf_sync_unlock (syncpoint)
The syncpoint I mentioned means lock mechanism; not doing cache operation.
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A to Task
B, we would need IPC operation to send and receive buffers properly between
those two tasks every time CPU or DMA access to buffers is started or
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the above
example, we would need IPC operation just one time. That way, I think we
could not only reduce performance overhead but also make user application
simplified. Of course, this approach can be used for all DMA device drivers
such as DRM. I'm not a specialist in v4l2 world so there may be missing
point.
Thanks,
Inki Dae
From: Lucas Stach <l.stach@pengutronix.de> Date: 2013-06-20 07:49:32
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
quoted
-----Original Message-----
From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
Behalf Of Russell King - ARM Linux
Sent: Thursday, June 20, 2013 3:29 AM
To: Inki Dae
Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
Cho; linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
quoted
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object.
And
quoted
the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt
handler):
quoted
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma
access
quoted
as long as possible.
What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
I didn't explain that enough. Sorry about that. 'nothing to do' means that a
dmabuf sync interface isn't called but existing functions are called. So
this may be explained again:
ioctl(dqbuf command)
|
|
dqbuf <- 1. dma_unmap_sg
2. dma_buf_sync_unlock (syncpoint)
The syncpoint I mentioned means lock mechanism; not doing cache operation.
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A to Task
B, we would need IPC operation to send and receive buffers properly between
those two tasks every time CPU or DMA access to buffers is started or
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the above
example, we would need IPC operation just one time. That way, I think we
could not only reduce performance overhead but also make user application
simplified. Of course, this approach can be used for all DMA device drivers
such as DRM. I'm not a specialist in v4l2 world so there may be missing
point.
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it. So
task A has to signal task B there is new data in the buffer to be
processed.
There is no need to share the buffer over and over again just to get the
two processes to work together on the same thing. Just share the fd
between both and then do out-of-band completion signaling, as you need
this anyway. Without this you'll end up with unpredictable behavior.
Just because sync allows you to access the buffer doesn't mean it's
valid for your use-case. Without completion signaling you could easily
end up overwriting your data from task A multiple times before task B
even tries to lock the buffer for processing.
So the valid flow is (and this already works with the current APIs):
Task A Task B
------ ------
CPU access buffer
----------completion signal--------->
qbuf (dragging buffer into
device domain, flush caches,
reserve buffer etc.)
|
wait for device operation to
complete
|
dqbuf (dragging buffer back
into CPU domain, invalidate
caches, unreserve)
<---------completion signal------------
CPU access buffer
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Russell King - ARM Linux <hidden> Date: 2013-06-20 08:18:28
On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
quoted
quoted
-----Original Message-----
From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
Behalf Of Russell King - ARM Linux
Sent: Thursday, June 20, 2013 3:29 AM
To: Inki Dae
Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
Cho; linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
quoted
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object.
And
quoted
the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt
handler):
quoted
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma
access
quoted
as long as possible.
What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
I didn't explain that enough. Sorry about that. 'nothing to do' means that a
dmabuf sync interface isn't called but existing functions are called. So
this may be explained again:
ioctl(dqbuf command)
|
|
dqbuf <- 1. dma_unmap_sg
2. dma_buf_sync_unlock (syncpoint)
The syncpoint I mentioned means lock mechanism; not doing cache operation.
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A to Task
B, we would need IPC operation to send and receive buffers properly between
those two tasks every time CPU or DMA access to buffers is started or
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the above
example, we would need IPC operation just one time. That way, I think we
could not only reduce performance overhead but also make user application
simplified. Of course, this approach can be used for all DMA device drivers
such as DRM. I'm not a specialist in v4l2 world so there may be missing
point.
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it. So
task A has to signal task B there is new data in the buffer to be
processed.
Hang on. Since when did dma_buf become another inter-process IPC
mechanism? That's *not* it's design goal, and there's other much
better mechanisms already provided.
What dma_buf is about is passing a DMA buffer from subsystem to another
subsystem via userspace without exposing precise details of the buffer
to userspace.
It is also not about passing a DMA buffer from one subsystem to another
to gain access to the buffer via the other subsystem and bypassing the
access arrangements of the source subsystem.
I'm beginning to think that _that_ should be enforced by subsystems, by
having any buffer imported into a subsystem either not able to be mapped
into userspace, or if it is mappable into userspace, it must be a
read-only mapping.
From: Lucas Stach <l.stach@pengutronix.de> Date: 2013-06-20 08:28:34
Am Donnerstag, den 20.06.2013, 09:17 +0100 schrieb Russell King - ARM
Linux:
On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
quoted
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
quoted
quoted
-----Original Message-----
From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
Behalf Of Russell King - ARM Linux
Sent: Thursday, June 20, 2013 3:29 AM
To: Inki Dae
Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
Cho; linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
quoted
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object.
And
quoted
the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt
handler):
quoted
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma
access
quoted
as long as possible.
What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
I didn't explain that enough. Sorry about that. 'nothing to do' means that a
dmabuf sync interface isn't called but existing functions are called. So
this may be explained again:
ioctl(dqbuf command)
|
|
dqbuf <- 1. dma_unmap_sg
2. dma_buf_sync_unlock (syncpoint)
The syncpoint I mentioned means lock mechanism; not doing cache operation.
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A to Task
B, we would need IPC operation to send and receive buffers properly between
those two tasks every time CPU or DMA access to buffers is started or
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the above
example, we would need IPC operation just one time. That way, I think we
could not only reduce performance overhead but also make user application
simplified. Of course, this approach can be used for all DMA device drivers
such as DRM. I'm not a specialist in v4l2 world so there may be missing
point.
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it. So
task A has to signal task B there is new data in the buffer to be
processed.
Hang on. Since when did dma_buf become another inter-process IPC
mechanism? That's *not* it's design goal, and there's other much
better mechanisms already provided.
That's why I said out-of-band completion signaling, particularly not
bound to the dma-buf itself.
My thinking was more along the lines of the wayland protocol, where one
process tells the compositor to use a buf as the pixel data for the next
frame and promises not to access it while the compositor uses it. When
the compositor finishes it tells the client that it's now free to reuse
the buffer. None of this is bound to the dma-buf.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-----Original Message-----
From: Lucas Stach [mailto:l.stach at pengutronix.de]
Sent: Thursday, June 20, 2013 4:47 PM
To: Inki Dae
Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
kernel at lists.infradead.org; linux-media at vger.kernel.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
quoted
quoted
-----Original Message-----
From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org]
On
quoted
quoted
Behalf Of Russell King - ARM Linux
Sent: Thursday, June 20, 2013 3:29 AM
To: Inki Dae
Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
YoungJun
quoted
quoted
Cho; linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
synchronization
quoted
quoted
framework
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
quoted
On the other hand, the below shows how we could enhance the
conventional
quoted
quoted
quoted
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object.
And
quoted
the syncpoint is performed by calling dma_buf_sync_lock(), and then
DMA
quoted
quoted
quoted
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt
handler):
quoted
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma
access
quoted
as long as possible.
What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
I didn't explain that enough. Sorry about that. 'nothing to do' means
that a
quoted
dmabuf sync interface isn't called but existing functions are called. So
this may be explained again:
ioctl(dqbuf command)
|
|
dqbuf <- 1. dma_unmap_sg
2. dma_buf_sync_unlock (syncpoint)
The syncpoint I mentioned means lock mechanism; not doing cache
operation.
quoted
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A to
Task
quoted
B, we would need IPC operation to send and receive buffers properly
between
quoted
those two tasks every time CPU or DMA access to buffers is started or
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the
above
quoted
example, we would need IPC operation just one time. That way, I think we
could not only reduce performance overhead but also make user
application
quoted
simplified. Of course, this approach can be used for all DMA device
drivers
quoted
such as DRM. I'm not a specialist in v4l2 world so there may be missing
point.
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it. So
task A has to signal task B there is new data in the buffer to be
processed.
There is no need to share the buffer over and over again just to get the
two processes to work together on the same thing. Just share the fd
between both and then do out-of-band completion signaling, as you need
this anyway. Without this you'll end up with unpredictable behavior.
Just because sync allows you to access the buffer doesn't mean it's
valid for your use-case. Without completion signaling you could easily
end up overwriting your data from task A multiple times before task B
even tries to lock the buffer for processing.
So the valid flow is (and this already works with the current APIs):
Task A Task B
------ ------
CPU access buffer
----------completion signal--------->
qbuf (dragging buffer into
device domain, flush caches,
reserve buffer etc.)
|
wait for device operation to
complete
|
dqbuf (dragging buffer back
into CPU domain, invalidate
caches, unreserve)
<---------completion signal------------
CPU access buffer
Correct. In case that data flow goes from A to B, it needs some kind of IPC between the two tasks every time as you said. Then, without dmabuf-sync, how do think about the case that two tasks share the same buffer but these tasks access the buffer(buf1) as write, and data of the buffer(buf1) isn't needed to be shared?
With dmabuf-sync is:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU writes something to buf1
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. copy buf1 to buf2
5. go to 1
Task B
---------------------------
1. dma_buf_sync_lock
2. CPU writes something to buf3
3. dma_buf_sync_unlock
4. qbuf the buf3(src) and buf1(dst)
4.1 insert buf3,1 to incoming queue
4.2 dma_buf_sync_lock <- syncpoint (call by kernel side)
5. stream on
5.1 dma_map_sg if ready, and move the buf to ready queue
5.2 get the buf from ready queue, and dma start.
6. dqbuf
6.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
6.2 dma_unmap_sg after dma operation completion
6.3 move the buf3,1 to outgoing queue
7. go to 1
Thanks,
Inki Dae
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Lucas Stach <l.stach@pengutronix.de> Date: 2013-06-20 10:13:30
Am Donnerstag, den 20.06.2013, 17:24 +0900 schrieb Inki Dae:
[...]
quoted
quoted
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A to
Task
quoted
B, we would need IPC operation to send and receive buffers properly
between
quoted
those two tasks every time CPU or DMA access to buffers is started or
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the
above
quoted
example, we would need IPC operation just one time. That way, I think we
could not only reduce performance overhead but also make user
application
quoted
simplified. Of course, this approach can be used for all DMA device
drivers
quoted
such as DRM. I'm not a specialist in v4l2 world so there may be missing
point.
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it. So
task A has to signal task B there is new data in the buffer to be
processed.
There is no need to share the buffer over and over again just to get the
two processes to work together on the same thing. Just share the fd
between both and then do out-of-band completion signaling, as you need
this anyway. Without this you'll end up with unpredictable behavior.
Just because sync allows you to access the buffer doesn't mean it's
valid for your use-case. Without completion signaling you could easily
end up overwriting your data from task A multiple times before task B
even tries to lock the buffer for processing.
So the valid flow is (and this already works with the current APIs):
Task A Task B
------ ------
CPU access buffer
----------completion signal--------->
qbuf (dragging buffer into
device domain, flush caches,
reserve buffer etc.)
|
wait for device operation to
complete
|
dqbuf (dragging buffer back
into CPU domain, invalidate
caches, unreserve)
<---------completion signal------------
CPU access buffer
Correct. In case that data flow goes from A to B, it needs some kind
of IPC between the two tasks every time as you said. Then, without
dmabuf-sync, how do think about the case that two tasks share the same
buffer but these tasks access the buffer(buf1) as write, and data of
the buffer(buf1) isn't needed to be shared?
Sorry, I don't see the point you are trying to solve here. If you share
a buffer and want its content to be clearly defined at every point in
time you have to synchronize the tasks working with the buffer, not just
the buffer accesses itself.
Easiest way to do so is doing sync through userspace with out-of-band
IPC, like in the example above. A more advanced way to achieve this
would be using cross-device fences to avoid going through userspace for
every syncpoint.
With dmabuf-sync is:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU writes something to buf1
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. copy buf1 to buf2
Random contents here? What's in the buffer, content from the CPU write,
or from V4L2 device write?
5. go to 1
Task B
---------------------------
1. dma_buf_sync_lock
2. CPU writes something to buf3
3. dma_buf_sync_unlock
4. qbuf the buf3(src) and buf1(dst)
4.1 insert buf3,1 to incoming queue
4.2 dma_buf_sync_lock <- syncpoint (call by kernel side)
5. stream on
5.1 dma_map_sg if ready, and move the buf to ready queue
5.2 get the buf from ready queue, and dma start.
6. dqbuf
6.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
6.2 dma_unmap_sg after dma operation completion
6.3 move the buf3,1 to outgoing queue
7. go to 1
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-----Original Message-----
From: Lucas Stach [mailto:l.stach at pengutronix.de]
Sent: Thursday, June 20, 2013 7:11 PM
To: Inki Dae
Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
kernel at lists.infradead.org; linux-media at vger.kernel.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
Am Donnerstag, den 20.06.2013, 17:24 +0900 schrieb Inki Dae:
[...]
quoted
quoted
quoted
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A
to
quoted
quoted
Task
quoted
B, we would need IPC operation to send and receive buffers properly
between
quoted
those two tasks every time CPU or DMA access to buffers is started
or
quoted
quoted
quoted
completed.
With dmabuf-sync:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU accesses buf
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. Send the buf to Task B (just one time)
5. go to 1
Task B
---------------------------
1. Wait for the buf from Task A (just one time)
2. qbuf the buf
1.1 insert the buf to incoming queue
3. stream on
3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
3.2 dma_map_sg if ready, and move the buf to ready queue
3.3 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
4.2 dma_unmap_sg after dma operation completion
4.3 move the buf to outgoing queue
5. go to 1
On the other hand, in case of using dmabuf-sync, as you can see the
above
quoted
example, we would need IPC operation just one time. That way, I
think we
quoted
quoted
quoted
could not only reduce performance overhead but also make user
application
quoted
simplified. Of course, this approach can be used for all DMA device
drivers
quoted
such as DRM. I'm not a specialist in v4l2 world so there may be
missing
quoted
quoted
quoted
point.
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it.
So
quoted
quoted
task A has to signal task B there is new data in the buffer to be
processed.
There is no need to share the buffer over and over again just to get
the
quoted
quoted
two processes to work together on the same thing. Just share the fd
between both and then do out-of-band completion signaling, as you need
this anyway. Without this you'll end up with unpredictable behavior.
Just because sync allows you to access the buffer doesn't mean it's
valid for your use-case. Without completion signaling you could easily
end up overwriting your data from task A multiple times before task B
even tries to lock the buffer for processing.
So the valid flow is (and this already works with the current APIs):
Task A Task B
------ ------
CPU access buffer
----------completion signal--------->
qbuf (dragging buffer into
device domain, flush caches,
reserve buffer etc.)
|
wait for device operation to
complete
|
dqbuf (dragging buffer back
into CPU domain, invalidate
caches, unreserve)
<---------completion signal------------
CPU access buffer
Correct. In case that data flow goes from A to B, it needs some kind
of IPC between the two tasks every time as you said. Then, without
dmabuf-sync, how do think about the case that two tasks share the same
buffer but these tasks access the buffer(buf1) as write, and data of
the buffer(buf1) isn't needed to be shared?
Sorry, I don't see the point you are trying to solve here. If you share
a buffer and want its content to be clearly defined at every point in
time you have to synchronize the tasks working with the buffer, not just
the buffer accesses itself.
Easiest way to do so is doing sync through userspace with out-of-band
IPC, like in the example above.
In my opinion, that's not definitely easiest way. What I try to do is to avoid using *the out-of-band IPC*. As I mentioned in document file, the conventional mechanism not only makes user application complicated-user process needs to understand how the device driver is worked-but also may incur performance overhead by using the out-of-band IPC. The above my example may not be enough to you but there would be other cases able to use my approach efficiently.
A more advanced way to achieve this
would be using cross-device fences to avoid going through userspace for
every syncpoint.
Ok, maybe there is something I missed. So question. What is the cross-device fences? dma fence?. And how we can achieve the synchronization mechanism without going through user space for every syncpoint; CPU and DMA share a same buffer?. And could you explain it in detail as long as possible like I did?
quoted
With dmabuf-sync is:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU writes something to buf1
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. copy buf1 to buf2
Random contents here? What's in the buffer, content from the CPU write,
or from V4L2 device write?
Please presume that buf1 is physically non contiguous memory, and buf2 is physically contiguous memory; device A without IOMMU is seeing buf2. We would need to copy buf1 to buf2 to send the contents of the buf1 to device A because DMA of the device A cannot access the buf1 directly. And CPU and V4L2 device don't share the contents of the buf1 but share the buf1 as storage.
Thanks,
Inki Dae
quoted
5. go to 1
Task B
---------------------------
1. dma_buf_sync_lock
2. CPU writes something to buf3
3. dma_buf_sync_unlock
4. qbuf the buf3(src) and buf1(dst)
4.1 insert buf3,1 to incoming queue
4.2 dma_buf_sync_lock <- syncpoint (call by kernel side)
5. stream on
5.1 dma_map_sg if ready, and move the buf to ready queue
5.2 get the buf from ready queue, and dma start.
6. dqbuf
6.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
6.2 dma_unmap_sg after dma operation completion
6.3 move the buf3,1 to outgoing queue
7. go to 1
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
From: Lucas Stach <l.stach@pengutronix.de> Date: 2013-06-21 08:56:33
Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
[...]
quoted
quoted
quoted
You already need some kind of IPC between the two tasks, as I suspect
even in your example it wouldn't make much sense to queue the buffer
over and over again in task B without task A writing anything to it.
So
quoted
quoted
task A has to signal task B there is new data in the buffer to be
processed.
There is no need to share the buffer over and over again just to get
the
quoted
quoted
two processes to work together on the same thing. Just share the fd
between both and then do out-of-band completion signaling, as you need
this anyway. Without this you'll end up with unpredictable behavior.
Just because sync allows you to access the buffer doesn't mean it's
valid for your use-case. Without completion signaling you could easily
end up overwriting your data from task A multiple times before task B
even tries to lock the buffer for processing.
So the valid flow is (and this already works with the current APIs):
Task A Task B
------ ------
CPU access buffer
----------completion signal--------->
qbuf (dragging buffer into
device domain, flush caches,
reserve buffer etc.)
|
wait for device operation to
complete
|
dqbuf (dragging buffer back
into CPU domain, invalidate
caches, unreserve)
<---------completion signal------------
CPU access buffer
Correct. In case that data flow goes from A to B, it needs some kind
of IPC between the two tasks every time as you said. Then, without
dmabuf-sync, how do think about the case that two tasks share the same
buffer but these tasks access the buffer(buf1) as write, and data of
the buffer(buf1) isn't needed to be shared?
Sorry, I don't see the point you are trying to solve here. If you share
a buffer and want its content to be clearly defined at every point in
time you have to synchronize the tasks working with the buffer, not just
the buffer accesses itself.
Easiest way to do so is doing sync through userspace with out-of-band
IPC, like in the example above.
In my opinion, that's not definitely easiest way. What I try to do is
to avoid using *the out-of-band IPC*. As I mentioned in document file,
the conventional mechanism not only makes user application
complicated-user process needs to understand how the device driver is
worked-but also may incur performance overhead by using the
out-of-band IPC. The above my example may not be enough to you but
there would be other cases able to use my approach efficiently.
Yeah, you'll some knowledge and understanding about the API you are
working with to get things right. But I think it's not an unreasonable
thing to expect the programmer working directly with kernel interfaces
to read up on how things work.
Second thing: I'll rather have *one* consistent API for every subsystem,
even if they differ from each other than having to implement this
syncpoint thing in every subsystem. Remember: a single execbuf in DRM
might reference both GEM objects backed by dma-buf as well native SHM or
CMA backed objects. The dma-buf-mgr proposal already allows you to
handle dma-bufs much the same way during validation than native GEM
objects.
And to get back to my original point: if you have more than one task
operating together on a buffer you absolutely need some kind of real IPC
to sync them up and do something useful. Both you syncpoints and the
proposed dma-fences only protect the buffer accesses to make sure
different task don't stomp on each other. There is nothing in there to
make sure that the output of your pipeline is valid. You have to take
care of that yourself in userspace. I'll reuse your example to make it
clear what I mean:
Task A Task B
------ -------
dma_buf_sync_lock(buf1)
CPU write buf1
dma_buf_sync_unlock(buf1)
---------schedule Task A again-------
dma_buf_sync_lock(buf1)
CPU write buf1
dma_buf_sync_unlock(buf1)
---------schedule Task B---------
qbuf(buf1)
dma_buf_sync_lock(buf1)
....
This is what can happen if you don't take care of proper syncing. Task A
writes something to the buffer in expectation that Task B will take care
of it, but before Task B even gets scheduled Task A overwrites the
buffer again. Not what you wanted, isn't it?
So to make sure the output of a pipeline of some kind is what you expect
you have to do syncing with IPC. And once you do CPU access it is a
synchronous thing in the stream of events. I see that you might want to
have some kind of bracketed CPU access even for the fallback mmap case
for things like V4L2 that don't provide explicit sync by their own, but
in no way I can see why we would need a user/kernel shared syncpoint for
this.
quoted
A more advanced way to achieve this
would be using cross-device fences to avoid going through userspace for
every syncpoint.
Ok, maybe there is something I missed. So question. What is the
cross-device fences? dma fence?. And how we can achieve the
synchronization mechanism without going through user space for every
syncpoint; CPU and DMA share a same buffer?. And could you explain it
in detail as long as possible like I did?
Yeah I'm talking about the proposed dma-fences. They would allow you to
just queue things into the kernel without waiting for a device operation
to finish. But you still have to make sure that your commands have the
right order and don't go wild. So for example you could do something
like this:
Userspace Kernel
--------- ------
1. build DRM command stream
rendering into buf1
2. queue command stream with execbuf
1. validate command stream
1.1 reference buf1 for writing
through dma-buf-mgr
2. kick off GPU processing
3. qbuf buf1 into V4L2
3. reference buf1 for reading
3.1 wait for fence from GPU to
signal
4. kick off V4L2 processing
So you don't need to wait in userspace and potentially avoid some
context switches, but you still have to make sure that GPU commands are
queued before you queue the V4L2 operation to make sure things get
operated on in the right order.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |