My branch at http://cgit.collabora.com/git/user/pq/weston.git/log/?h=next contains an experimental implementation of "zlinux_dmabuf" protocol (the "z" means experimental). This protocol allows clients to wrap a dmabuf into a wl_buffer, and push that into the compositor for display. It is especially useful for video players using hardware decoding, and we have code somewhere to use it in GStreamer. The compositor then uses GBM to import that wl_buffer as a bo for compositing with GL (via EGLImage) or direct scanout as a DRM FB object. We have demonstrated this pipeline to work. However, the protocol design is far far away from complete. Even the kernel developers are still discussing, how cross-device support for dmabufs should work, and what is the proper information split between the kernel and the user space. How do you communicate, or even describe, things like tiling formats. But, we should start from somewhere, and this task about pushing the user space part forward a bit. All the zlinux_dmabuf related patches, including some DRM backend stuff, should be extracted from the 'next' branch and rebased on Weston master. The next step is to add a round-trip to the wl_buffer factory protocol in zlinux_dmabuf. The round-trip is needed, because there is no way to communicate all dmabuf constraints from the compositor to a client before-hand. In fact, there are existing APIs like EGL (the dmabuf import extension) that are based on trial-and-error rather than knowing the constraints before-hand. The constraints are simply too complicated and changing to be described in a Wayland protocol extension. When wrapping a dmabuf in a wl_buffer, the client should first send all dmabuf data to the compositor. Then the compositor somehow (*furious hand-waving*) determines if it can use the dmabuf at least in its fallback compositing path, and sends a reply to the client. If the reply is "ok", then the client has a wl_buffer it can use. Note, that this round-trip happens only at the time the wl_buffer is being created, and you can create multiple dmabuf-based wl_buffers with the same round-trip, and do whatever else you want to do. After that, we should try to get this into Weston upstream for more public development, still as an experimental protocol that is subject to rewriting as needed.
If you use Mesa, you need version 10.2.7 or later for EXT_image_dma_buf_import extension to work right. See bug #76188.
I noticed an RFC patch on dri-devel@ for the kernel/user ABI: http://lists.freedesktop.org/archives/dri-devel/2014-December/073775.html Rob, I hope you don't mind me adding you to CC, I think you might be interested in keeping an eye on the Weston side.
(In reply to Pekka Paalanen from comment #2) > I noticed an RFC patch on dri-devel@ for the kernel/user ABI: > http://lists.freedesktop.org/archives/dri-devel/2014-December/073775.html > > Rob, I hope you don't mind me adding you to CC, I think you might be > interested in keeping an eye on the Weston side. no prob.. btw, IMHO once we've settled on how we do this for kms/addfb2, I think it is probably a good idea to extend the EGL img extension, wayland proto, etc, in a similar way
Yeah, the EGL thing is really harsh. One of the main motivations behind wanting a query is to avoid the EGL trap where we literally have no idea, and just have to guess as to which _formats_ are supported. I get that random arbitrary combinations may fail for any reason, but not having a format query is really harsh.
Louis-Francis has posted a new RFC series for Weston: http://lists.freedesktop.org/archives/wayland-devel/2014-December/019006.html
It look similar to what I have propose sometime ago so I'm happy to see we working on this topic. Do you think it would possible to avoid duplicate formats definition ? it is painful when you write client to deal with both SHM and DMABUF formats definition. simple-dmabuf.c use intel specific functions for buffer management, could you make it more generic by using only standard libdrm function ? You make linux_dmabuf works for gl-renderer what about pixman-renderer ? Which GStreamer video sink do you use as client ? How do you allocate the buffers in this sink ?
(In reply to Benjamin Gaignard from comment #6) > Do you think it would possible to avoid duplicate formats definition ? it is > painful when you write client to deal with both SHM and DMABUF formats > definition. The namespace is different, and we don't really have a good place for global constants in Wayland. I suppose one could re-use the wl_shm format list... or just pick formats from drm_fourcc.h directly, since I believe these are meant to be identical. The thing with wl_shm is that it is not limited to systems with dmabuf, while I think all dmabuf systems already have drm_fourcc.h. > simple-dmabuf.c use intel specific functions for buffer management, could > you make it more generic by using only standard libdrm function ? If GBM offers it, sure. It just means that simple-dmabuf will depend on Mesa basically, and probably even need to use GL to fill the buffer. Or maybe some V4L device could create and export dmabufs. > You make linux_dmabuf works for gl-renderer what about pixman-renderer ? Pixman renderer would require mmap() support which is not guaranteed, but sure, now that there is a roundtrip involved, Weston could ask the pixman-renderer if it can handle the tentative new buffer. As you can see, the series is still missing all about the optional mmap path, because we needed the accelerated path working first. > Which GStreamer video sink do you use as client ? > How do you allocate the buffers in this sink ? I'll leave these questions to lfrb and others.
(In reply to Benjamin Gaignard from comment #6) > Which GStreamer video sink do you use as client ? > How do you allocate the buffers in this sink ? The GStreamer part should probably be discussed here. https://bugzilla.gnome.org/show_bug.cgi?id=711155 I'll try to comment base on what should concern wayland, adding a little context. In GStreamer there will is two possible display element working on Wayland, glimagesink and waylandsink. glimagesink uses client side EGL/OpenGL/GLES2 to render the video. It will most likely never allocated DMABUF, but will most likely be able to import them. This can already be implemented without any changes to current Wayland protocols. waylansink, uses wayland specific representation for wrapping video memory. It's a smarter choice, since it gives the compositor the choices of the smartest renderer. Adding DMABUF in this case requires protocols. The patches submitted at the beginning of the year were not merged because of open issues, including usage of driver specific APIs and that this new protocol was still changing very quickly. What has been proposed to Benjamin was to focus on getting importation of DMABUF first, and come back with allocation when this problem get resolved in a better way. The allocation of DMABUF remains an open issue for everyone. A small comment though, if we want this work to be usable in waylansink. By it's nature, the alignment of a DMABUF frame received might not match the required alignment by the GPU or HW mixer, or any HW involved. A miss-match should never prevent the rendering of a buffer unless the buffer is not mappable to user space. This is often not so simple as only kernel space can figure-out there is a miss-match (at least at the moment). It is important to handle this nicely and manage non-destructive fallback.
Since the Wayland bug/task tracking is moving to Phabricator, here is the link to the Maniphest task: http://phabricator.freedesktop.org/T13 An updated revision has been posted there containing these major changes since RFCv1: - Check if DMABUF is supported by the renderer to allow graceful degradation - Add support for the 64-bit layout qualifier (tiling, compression, etc.) [0] - Use DRM fourcc format codes (drm_fourcc.h) as authoritative source - Cache EGLImages created by importing DMABUF buffers - General improvements in errors handling and documentation All comments and reviews should be done in Phabricator
Sorry, I don't think we should completely move to Phab just yet. It is still in evaluation, testing and drive-in phase, where a limited set of people work on it. We are trying to establish proper work flows before announcing it for public evaluation. Until then, I think we should keep this fd.o bug as the primary place. Once we've done our own reviews in Phab (which is public, just not announced), we'll send the series to wayland-devel@ as usual and note it here. Sorry for the confusion. :-) Still, feel free to poke around Phab and see what it has.
Okay, since Phab is so nice for reviewing things (though less nice for submitting things for now), there is a new revision of patches attached to http://phabricator.freedesktop.org/T13 Feel free to have a look and leave comments. I will address them and then do a submission to wayland-devel@ the old way which will become the RFCv2 series, or preferably just v2 series for landing in Weston. This is also available in https://git.collabora.com/cgit/user/pq/weston.git/log/?h=dmabuf-WIP (Note: dmabuf-WIP branch will get rewritten when I update the series.)
v2 has been posted to wayland-devel@: http://lists.freedesktop.org/archives/wayland-devel/2015-July/023124.html
With Daniel Vetter's and Carlos Olmedo Escobar's comments addressed, v3 (a trivial rebase) of this series is now pushed to Weston: f3c8336..5386898 master -> master We can continue testing, developing, and changing the dmabuf protocol in Weston until we are happy with it. I wonder if we should leave this bug open until the protocol is deemed stable, or should we close it now?
Let's just close it. Mesa and GStreamer (at least) are using it and the sky doesn't seem to have quite fallen in yet.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.