Hello all,
I have an use-case, where a buffer "B" needs to be further operated upon by an additional operator (ex, CPU or 2D HW). The further operation is typically in smaller subrects of "B".
While looking through the dma-buf API, I do not see a way by which I can specify properties of subrects in a buffer which can be specified as "read-only" to one user of the buffer, while the other user can go ahead and update it. If we have this mechanism, we can do below steps to reduce latency of locking/waiting for one full buffer update, and then making it available to the next consumer.
(1) Create dma-buf using usual methods
(2) Exported to 2 users - ex GPU, and 2D HW
(3) GPU updates specific subrects
(4) 2D HW updates specific subrects
(5) When both (3) and (4) are complete, the buffer is available to next consumer. Since (3) and (4) can run in parallel, latency can be reduced.
If there is a way by which this can already be done, I would appreciate if someone can point me to it.
regards Prabindh
Hi Prabindh,
First up, warm wishes for a Happy New Year 2014 to you, and everyone!
Secondly, apologies for the delay in this response - I guess the holiday season too didn't help much.
Now, to your question - at the moment, dma-buf buffers don't have a concept of sub-rects AFAIK - this is because dma-buf framework by itself is agnostic of the dimensional properties of the buffer, so 'subrects' is not a relevant term for dma-buf buffers.
That said, there is work done recently by Maarten Lankhorst on adding fencing support to dma-buf, which should help in reducing latencies. In your example, this could eliminate the latency when the GPU kernel component informs userspace of completion and the userspace then tells 2D HW kernel component to go update. The 2D HW could instead be waiting on a fence for the same dma-buf, which gets signalled by the GPU kernel component, so the kernelspace-userspace-kernelspace latency is taken out.
I would still leave GPU experts (Daniel, Rob, Maarten ?) to comment on how the use case you mentioned works in other hardware.
Best regards, ~Sumit.
On 24 December 2013 13:33, Sundareson, Prabindh prabu@ti.com wrote:
Hello all,
I have an use-case, where a buffer "B" needs to be further operated upon by an additional operator (ex, CPU or 2D HW). The further operation is typically in smaller subrects of "B".
While looking through the dma-buf API, I do not see a way by which I can specify properties of subrects in a buffer which can be specified as "read-only" to one user of the buffer, while the other user can go ahead and update it. If we have this mechanism, we can do below steps to reduce latency of locking/waiting for one full buffer update, and then making it available to the next consumer.
(1) Create dma-buf using usual methods
(2) Exported to 2 users - ex GPU, and 2D HW
(3) GPU updates specific subrects
(4) 2D HW updates specific subrects
(5) When both (3) and (4) are complete, the buffer is available to next consumer. Since (3) and (4) can run in parallel, latency can be reduced.
If there is a way by which this can already be done, I would appreciate if someone can point me to it.
regards Prabindh
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
Hello Sumit,
Thanks for the clarification, will check the work done by Maarten.
regards, Prabindh
-----Original Message----- From: Sumit Semwal [mailto:sumit.semwal@linaro.org] Sent: Monday, January 06, 2014 11:44 AM To: Sundareson, Prabindh Cc: linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] Specifying subrect properties in dma-buf
Hi Prabindh,
First up, warm wishes for a Happy New Year 2014 to you, and everyone!
Secondly, apologies for the delay in this response - I guess the holiday season too didn't help much.
Now, to your question - at the moment, dma-buf buffers don't have a concept of sub-rects AFAIK - this is because dma-buf framework by itself is agnostic of the dimensional properties of the buffer, so 'subrects' is not a relevant term for dma-buf buffers.
That said, there is work done recently by Maarten Lankhorst on adding fencing support to dma-buf, which should help in reducing latencies. In your example, this could eliminate the latency when the GPU kernel component informs userspace of completion and the userspace then tells 2D HW kernel component to go update. The 2D HW could instead be waiting on a fence for the same dma-buf, which gets signalled by the GPU kernel component, so the kernelspace-userspace-kernelspace latency is taken out.
I would still leave GPU experts (Daniel, Rob, Maarten ?) to comment on how the use case you mentioned works in other hardware.
Best regards, ~Sumit.
On 24 December 2013 13:33, Sundareson, Prabindh prabu@ti.com wrote:
Hello all,
I have an use-case, where a buffer "B" needs to be further operated upon by an additional operator (ex, CPU or 2D HW). The further operation is typically in smaller subrects of "B".
While looking through the dma-buf API, I do not see a way by which I can specify properties of subrects in a buffer which can be specified as "read-only" to one user of the buffer, while the other user can go ahead and update it. If we have this mechanism, we can do below steps to reduce latency of locking/waiting for one full buffer update, and then making it available to the next consumer.
(1) Create dma-buf using usual methods
(2) Exported to 2 users - ex GPU, and 2D HW
(3) GPU updates specific subrects
(4) 2D HW updates specific subrects
(5) When both (3) and (4) are complete, the buffer is available to next consumer. Since (3) and (4) can run in parallel, latency can be reduced.
If there is a way by which this can already be done, I would appreciate if someone can point me to it.
regards Prabindh
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
-- Thanks and regards,
Sumit Semwal Graphics Engineer - Graphics working group Linaro.org │ Open source software for ARM SoCs
linaro-mm-sig@lists.linaro.org
-
Sumit Semwal -
Sundareson, Prabindh