From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
The goal of this serie of patches is to add a way to use
dmabuf file descriptor inside wayland and weston.
In a context where there is no Mesa EGL (and so no wl_drm protocol) wl_dmabuf
could be used as an alternative to shm to share buffers between hardware
devices. If your hardware device (video decoder, renderer, etc...) need
physical contiguous memory (obviously don't have MMU) wl_dmabuf may save
the cost of one copy compare to shm.
shm case:
videodecoder --(copy into shm_buffer)--> weston(+pixman) --> HW renderer
dmabuf case:
videodecoder --(directly write in dmabuf buffer)--> weston(+pixman) --> HW renderer
The server is responsible to send its supported pixel formats and the device
name to be used by the client to allocate buffers.
While mmap() call on dmabuf file descriptor result isn't guaranty on all
architectures both server and client should take care of it before accessing
to buffer data to avoid segfault.
This series of patches include wayland and weston modifications.
An example of how use wl_dmabuf is provided in weston/clients/simple-dmabuf.c
=== Wayland ===
Benjamin Gaignard (1):
Add wl_dmabuf protocol
protocol/Makefile.am | 6 +-
protocol/wayland-dmabuf.xml | 128 ++++++++++++++++++++++++
src/Makefile.am | 12 ++-
src/wayland-dmabuf.c | 231 +++++++++++++++++++++++++++++++++++++++++++
src/wayland-dmabuf.h | 123 +++++++++++++++++++++++
5 files changed, 496 insertions(+), 4 deletions(-)
create mode 100644 protocol/wayland-dmabuf.xml
create mode 100644 src/wayland-dmabuf.c
create mode 100644 src/wayland-dmabuf.h
=== Weston ===
Benjamin Gaignard (2):
compositor-drm: allow to be a wl_dmabuf server
add simple-dmabuf client
clients/Makefile.am | 11 ++
clients/simple-dmabuf.c | 469 +++++++++++++++++++++++++++++++++++++++++++++++
configure.ac | 5 +
src/compositor-drm.c | 83 ++++++++-
src/compositor.c | 4 +-
src/compositor.h | 2 +
src/pixman-renderer.c | 93 +++++++---
7 files changed, 637 insertions(+), 30 deletions(-)
create mode 100644 clients/simple-dmabuf.c
--
1.7.9.5
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
From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
The goal of this serie of patches is to add a way to use
dmabuf file descriptor inside wayland and weston.
In a context where there is no Mesa EGL (and so no wl_drm protocol) wl_dmabuf
could be used as an alternative to shm to share buffers between hardware
devices. If your hardware device (video decoder, renderer, etc...) need
physical contiguous memory (obviously don't have MMU) wl_dmabuf may save
the cost of one copy compare to shm.
shm case:
videodecoder --(copy into shm_buffer)--> weston(+pixman) --> HW renderer
dmabuf case:
videodecoder --(directly write in dmabuf buffer)--> weston(+pixman) --> HW renderer
The server is responsible to send its supported pixel formats and the device
name to be used by the client to allocate buffers.
While mmap() call on dmabuf file descriptor result isn't guaranty on all
architectures both server and client should take care of it before accessing
to buffer data to avoid segfault.
=== Wayland ===
Benjamin Gaignard (1):
Add wl_dmabuf protocol
protocol/Makefile.am | 6 +-
protocol/wayland-dmabuf.xml | 133 +++++++++++++++++++++
src/Makefile.am | 12 +-
src/wayland-dmabuf.c | 279 +++++++++++++++++++++++++++++++++++++++++++
src/wayland-dmabuf.h | 136 +++++++++++++++++++++
5 files changed, 562 insertions(+), 4 deletions(-)
create mode 100644 protocol/wayland-dmabuf.xml
create mode 100644 src/wayland-dmabuf.c
create mode 100644 src/wayland-dmabuf.h
=== Weston ===
Benjamin Gaignard (1):
compositor-drm: allow to be a wl_dmabuf server
src/compositor-drm.c | 168 +++++++++++++++++++++++++++++++++++++++++++++++--
src/compositor.c | 4 +-
src/compositor.h | 2 +
src/pixman-renderer.c | 86 ++++++++++++++++++-------
4 files changed, 230 insertions(+), 30 deletions(-)
--
1.7.9.5
Hi all,
I'm working for Linaro on enabling a zero copy path in GStreamer by
using dmabuf.
To make this possible I have patched gst wayland sink to use wayland
drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155
Today wayland drm protocol is limited to Mesa so I have decided to
move it into wayland-core.
My hardware doesn't have gpu support yet so I have patched weston
(pixman) to allow usage of wl_drm buffers.
With this I able to share/use a buffer allocated by DRM in gstreamer
pipeline even if I don't have gpu and EGL.
What do you think about make wayland drm protocol available like this ?
Please note those patches are for wayland/weston 1.1.0
Regards,
Benjamin
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard <keithp(a)keithp.com> wrote:
> Daniel Vetter <daniel(a)ffwll.ch> writes:
>
>> Hm, where do we have the canonical source for all these fourcc codes? I'm
>> asking since we have our own copy in the kernel as drm_fourcc.h, and that
>> one is part of the userspace ABI since we use it to pass around
>> framebuffer formats and format lists.
>
> I think it's the kernel? I really don't know, as the whole notion of
> fourcc codes seems crazy to me...
>
> Feel free to steal this code and stick it in the kernel if you like.
Well, I wasn't ever in favour of using fourcc codes since they're just
not standardized at all, highly redundant in some cases and also miss
lots of stuff we actually need (like all the rgb formats).
Cc'ing the heck out of this to get kernel people to hopefully notice.
Maybe someone takes charge of this ... Otherwise meh.
>> Just afraid to create long-term maintainance madness here with the
>> kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely
>> we'll ever accept srgb for framebuffers though.
>
> Would suck to collide with something we do want though.
Yeah, it'd suck. But given how fourcc works we probably have that
already, just haven't noticed yet :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch