[ANNOUNCE] wayland-protocols 1.17
wayland-protocols 1.17 is now available. This versions include two new unstable protocols: linux-explicit-synchronization - A Linux specific mechanism for explicit per-surface buffer synchronization. primary-selection - A clipboard like mechanism mimicking primary selection on X11, commonly known as "middle-click-paste". The license tag for the fullscreen shell was also corrected. Here is the shortlog: Alexandros Frantzis (1): Add zwp_linux_explicit_synchronization_v1 Johan Klokkhammer Helsing (1): fullscreen-shell: Add missing license tag Jonas Ådahl (1): configure.ac: Bump version to 1.17 emersion (1): unstable: add primary-selection protocol git tag: 1.17 http://wayland.freedesktop.org/releases/wayland-protocols-1.17.tar.xz MD5: 55ddd5fdb02b73b9de9559aaec267315 wayland-protocols-1.17.tar.xz SHA1: 7d2569c838c776545e3eb1b1049b9c37178aae24 wayland-protocols-1.17.tar.xz SHA256: df1319cf9705643aea9fd16f9056f4e5b2471bd10c0cc3713d4a4cdc23d6812f wayland-protocols-1.17.tar.xz PGP: http://wayland.freedesktop.org/releases/wayland-protocols-1.17.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
Hi Simon, On Fri, 2018-11-02 at 18:49 +, Simon Ser wrote: > On Friday, November 2, 2018 12:30 PM, Philipp Zabel > wrote: > > > > + > > > > + > > > > +This event advertizes the primary device that the server > > > > prefers. There > > > > +is exactly one primary device. > > > > Which device should this be if the scanout engine is separate from the > > render engine (e.g. IPU/imx-drm and GPU/etnaviv on i.MX6) > > When the surface hints are created, I expect the compositor to send the device > it uses for compositing as the primary device (assuming it's using only one > device). i.MX6 has a separate scanout device without any acceleration capabilities except some hardware overlay planes, and a pure GPU render device without any connection to the outside world. The compositor uses both devices for compositing and output. > > When the surface becomes fullscreen on a different GPU (meaning it becomes > fullscreen on an output which is managed by another GPU), I'd expect the > compositor to change the primary device for this surface to this other GPU. > > If the compositor uses multiple devices for compositing, it'll probably switch > the primary device when the surface is moved from one GPU to the other. > > I'm not sure how i.MX6 works, but: even if the same GPU is used for > compositing > and scanout, but the compositing preferred formats are different from the > scanout preferred formats, the compositor can update the preferred format > without changing the preferred device. > > Is there an issue with this? Maybe something should be added to the protocol > to > explain it better? It is not clear to me from the protocol description whether the primary device means the scanout engine or the GPU, in case they are different. What is the client process supposed to do with this fd? Is it expected to be able to render on this device? Or use it to allocate the optimal buffers? > > What about contiguous vs non-contiguous memory? > > > > On i.MX6QP (Vivante GC3000) we would probably want the client to always > > render DRM_FORMAT_MOD_VIVANTE_SUPER_TILED, because this can be directly > > read by both texture samplers (non-contiguous) and scanout (must be > > contiguous). > > > > On i.MX6Q (Vivante GC2000) we always want to use the most efficient > > DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED, because neither of the > > supported render formats can be sampled or scanned out directly. > > Since the compositor has to resolve into DRM_FORMAT_MOD_VIVANTE_TILED > > (non-contiguous) for texture sampling or DRM_FORMAT_MOD_LINEAR > > (contiguous) for scanout, the client buffers can always be non- > > contiguous. > > > > On i.MX6S (Vivante GC880) the optimal render format for texture sampling > > would be DRM_FORMAT_MOD_VIVANTE_TILED (non-contiguous) and for scanout > > DRM_FORMAT_MOD_VIVANTE_SUPER_TILED (non-contiguous) which would be > > resolved into DRM_FORMAT_MOD_LINEAR (contiguous) by the compositor. > > I think all of this works with Daniel's design. > > > All three could always handle DRM_FORMAT_MOD_LINEAR (contiguous) client > > buffers for scanout directly, but those would be suboptimal if the > > compositor decides to render on short notice, because the client would > > have already resolved into linear and then the compositor would have to > > resolve back into a texture sampler tiling format. > > Is the concern here that switching between scanout and compositing is > non-optimal until the client chooses the preferred format? My point is just that whether or not the buffer must be contiguous in physical memory is the essential piece of information on i.MX6QP, whereas the optimal tiling modifier is the same for both GPU composition and direct scanout cases. If the client provides non-contiguous buffers, the "optimal" tiling doesn't help one bit in the scanout case, as the scanout hardware can't read from those. regards Philipp ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_hints
On multi-GPU setups, multiple devices can be used for rendering. Clients need hints about the device in use by the compositor. For instance, if they render on another GPU, then they need to make sure the memory is accessible between devices and that their buffers are not placed in hidden memory. This commit introduces a new wp_linux_dmabuf_hints object. This object advertises a preferred device via a file descriptor and a set of preferred formats/modifiers. Each object is bound to a wl_surface and can dynamically update its hints. This enables fine-grained per-surface optimizations. For instance, when a surface is scanned out on a GPU the compositor isn't compositing with, the preferred device can be set to this GPU to avoid unnecessary roundtrips. A hint object can also be standalone for clients that don't support per-surface hints. Signed-off-by: Simon Ser --- Changes from RFC to v1: - Added get_default_hints for clients that don't support per-surface hints - Added preference tranches for formats and modifiers - Made all hints optional for e.g. nested compositors that don't know the DRM device they're rendering with - Clarified that clients can ignore hints .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 99 ++- 1 file changed, 97 insertions(+), 2 deletions(-) diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml index 154afe2..2751d37 100644 --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml @@ -24,7 +24,7 @@ DEALINGS IN THE SOFTWARE. - + Following the interfaces from: https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt @@ -35,6 +35,9 @@ the set of supported formats and format modifiers is sent with 'format' and 'modifier' events. + Clients can use the get_surface_hints request to get dmabuf hints for a + particular surface. + The following are required from clients: - Clients must ensure that either all data in the dma-buf is @@ -138,9 +141,29 @@ + + + +This request creates a new wp_linux_dmabuf_hints object not bound +to a particular surface. This object will deliver hints about dmabuf +parameters to use if the client doesn't support per-surface hints +(see get_surface_hints). + + + + + + +This request creates a new wp_linux_dmabuf_hints object for the +specified wl_surface. This object will deliver hints about dmabuf +parameters to use for buffers attached to this surface. + + + + - + This temporary object is a collection of dmabufs and other parameters that together form a single logical buffer. The temporary @@ -342,7 +365,79 @@ + + + + + This object advertises dmabuf parameters hints. Such hints include the + primary device and the formats/modifiers that are preferred. + + These hints are sent once when this object is created and whenever they + change. The done event is always sent once after all hints have been sent. + + All hints are optional. The compositor can send the done event without any + hint. + + The client is allowed to ignore hints and pick a format/modifier + advertised as supported by the wp_linux_dmabuf interface. + + The formats and modifiers are groupped by tranches of preference. For each + tranch, some modifier events are sent and then a tranch event finishes + the list. The tranches are sent in descending order of preference. All + formats and modifiers in the same tranch have the same preference. + + + + +Using this request a client can tell the server that it is not going to +use the wp_linux_dmabuf_hints object anymore. + + + + + +This event advertises the primary device that the server prefers. There +is no more than one primary device. + + + + + + +This event advertises the formats that the server prefers, along with +the modifiers preferred for each format. The preferred formats must +have been advertised as supported formats by the wp_linux_dmabuf +interface. +These events are split in preference tranches by the tranch event. + +For the definition of the format and modifier codes, see the +wp_linux_buffer_params::create request. + + + + + + + + +This event splits modifier events in preference tranches. It is sent +after a set of modifiers/formats and represents the end of a tranch. The +next tranch will have a lower preference. + + + + + +This event is sent after all properties of a wp_linux_dmabuf_hints +object have
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Mon, 12 Nov 2018 11:15:25 + Daniel Stone wrote: > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > > I can add that while pushing upstream, if there are no other changes > > coming. > > > > Reviewed-by: Pekka Paalanen > > > > You have ensured that the C files generated from this revision build > > fine in Weston, right? > > > > David, Daniel, since your name is in the maintainers, can I have your > > R-b, please? > > The protocol is: > Reviewed-by: Daniel Stone > > The Weston implementation looks pretty good so far, though there's no > full implementation of release yet. Pushed: 18032f6..19ec5dc master -> master I dropped Reveman from the maintainers due to lack of R-b or S-o-b. I welcome a patch to add him back if he wants to. Thanks, pq pgp4iRmRaVHUY.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland intermediate sized data transfer
On Mon, 12 Nov 2018 14:48:19 +0200 Pekka Paalanen wrote: > Quite likely we need to revisit this in any case. Using shared memory > feels complicated, but OTOH it *is* relatively lot of data. Even the > kernel UABI does not use a flat list of format+modifier but a fairly > "interesting" bitfield encoding. That's probably not appropriate for > Wayland though, so maybe we have to use shared memory for it. Hi, having thought about this, I have the feeling that Wayland handles well tiny bits of data as protocol messages and large chunks of data as shared memory file descriptors, but it seems we lack a good solution for intermediate sized bits of data in the range 1 kB - 8 kB, just to throw some random numbers up. It is too risky to put these through the protocol messages in line, but the trouble of setting up a shared memory file seems disproportionate to the amount of data. Yet, it seems that setting up a shared memory file is the only solution since the in line data is too risky. I started wondering if we should have a generic shared memory interface, something like the following sketch of a Wayland extension. interface shm_factory Is the global. - request: create_shm_file(new shm_file, fd, size, seals, direction) Creates a new shm_file object that refers to the memory backing the fd, of the given size, and being sealed with the mentioned seals. Direction means whether the server or the client will be the writer, so this will be a one-way street but a re-usable one. (This is a good chance to get memfd and seals properly used.) interface shm_file Represents a piece of shared memory. Comes in two mutually exclusive flavours: - server-writable - client-writable Has a fixed size. The usage pattern is that the writer signals the reader when it needs to copy the data out. This is done by a custom protocol message carrying a shm_file as an argument, which makes the shm_file read-locked. The reader copies the data out of the shared memory and sends client_read_done or server_read_done ASAP, releasing the read-lock. While the shm_file is read-locked, the writer may not write into it. While the shm_file is not read-locked, the reader may not read it. - request: client_read_done Sent by the client when it has copied the data out. Releases the read-lock. - event: server_read_done Sent by the server when it has copied the data out. Releases the read-lock. When e.g. zwp_linux_dmabuf would provide the list of pixel formats and modifiers, the server needs to first send the required shared memory size to the client, the client creates a server-writable shm_file, and sends it to the server. The server fills in the data and sends an event with the shm_file as an argument that tell the client to read it (sets the read-lock). The rest goes according to the the generic protocol above. Why all the roundtripping to get the shm_file created? Because I would prefer the memory allocation is always accounted to the client, not the server. We should try to keep server allocations on behalf of clients to a minimum so that OOM killer etc. can find the right culprit. Why so much copying? Because the amount of data should be small enough that copying it is insignificant. By assuming that readers maintain their own copy, the protocol is simpler. No need to juggle multiple shm_files like we do with wl_buffers. Why unidirectional? To keep it simple. Need bidirectional transfers? Make one shm_file for each direction. Isn't creating and tearing down shared memory relatively expensive? Yes, but shm_file is meant to be repeatedly re-used. After reader has read, the writer can write again. No need to tear it down, if you expect repeated transfers. While writing this, I have a strong feeling I am reinventing the wheel here... Just throwing this idea out there, not sure if it was a good one. Thanks, pq pgpnLf27xheVH.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Mon, 12 Nov 2018 12:16:04 + Simon Ser wrote: > On Monday, November 12, 2018 10:18 AM, Pekka Paalanen > wrote: > > On Sat, 10 Nov 2018 13:34:31 + > > Simon Ser wrote: > > > > > On Monday, November 5, 2018 9:57 AM, Pekka Paalanen > > > wrote: > > > > > > Yeah. Another option is to send a wl_array of modifiers per format > > > > > > and > > > > > > tranch. > > > > > > > > > > True. Any reason why this hasn't been done in the global? > > > > > > > > For formats? Well, it is simpler without a wl_array, and there might be > > > > a lot of formats. > > > > > > > > Could there be a lot of modifiers per format? Would a wl_array make > > > > anything easier? Just a thought. > > > > > > It's true that for this list of formats sorted by preference, we'll > > > probably > > > need to split modifiers anyway so I don't think we'd benefit a lot from > > > this > > > approach. > > > > Hi Simon, > > > > just to be clear, I was thinking of something like: > > > > event(uint format, wl_array(modifiers)) > > > > But I definitely do not insist on it if you don't see any obvious > > benefits with it. > > Yeah. I think the benefits would not be substantial as we need to "split" > these > to order them by preference. So it would look like so: > > event(format1, wl_array(modifiers)) > barrier() > event(format1, wl_array(modifiers)) > event(format2, wl_array(modifiers)) > barrier() > event(format1, wl_array(modifiers)) > barrier() > > Also this is not consistent with the rest of the protocol. Maybe we can > discuss > this again for linux-dmabuf-unstable-v2. > > > It seems you and I made very different assumptions on how the hints > > would be sent, I only realized it just now. More about that below. > > > > > > > > I suppose it will be enough to send tranches for just the currently > > > > > > used format? Otherwise it could be "a lot" of data. > > > > > > > > > > What do you mean by "the currently used format"? > > > > > > > > This interface is used to send clients hints after they are already > > > > presenting, which means they already have a format chosen and probably > > > > want to stick with it, just changing the modifiers to be more optimal. > > > > > > If we only send the modifiers for the current format, how do clients tell > > > the > > > difference between the initial hints (which don't have a "currently used > > > format") and the subsequent hints? > > > > I'm not sure I understand why they would need to see the difference. > > But yes, I was short-sighted here and didn't consider the > > initialization when a surface is not mapped yet. I didn't expect that > > hints can be calculated if the surface is not mapped, but of course a > > compositor can provide some defaults. I suppose the initial default > > hints would boil down to what is most efficient to composite. > > > > > > > I expect clients to bind to this interface and create a surface hints > > > > > object > > > > > before the surface is mapped. In this case there's no "currently used > > > > > format". > > > > > > > > Right, that's another use case. > > > > > > > > > It will be a fair amount of data, yes. However it's just a list of > > > > > integers. > > > > > When we send strings over the protocol (e.g. toplevel title in > > > > > xdg-shell) it's > > > > > about the same amount of data I guess. > > > > > > > > If the EGLConfig or GLXFBConfig or GLX visual lists are of any > > > > indication... yes, they account for depth, stencil, aux, etc. but then > > > > we will have modifiers. > > > > > > > > We already advertise the list of everything supported of format+modifer > > > > in the linux_dmabuf extension. Could we somehow minimize the number of > > > > recommended format+modifiers in hints? Or maybe that's not a concern > > > > for the protocol spec? > > > > > > I'm not sure. > > > > > > After this patch, I'm not even sure how the formats+modifiers advertised > > > by the > > > global work. Are these formats+modifiers supported on the GPU the > > > compositor > > > uses for rendering? Intersection or union of formats+modifiers supported > > > on all > > > GPUs? > > > > The format+modifier advertised by the global before this patch are the > > ones that can work at all, or the compositor is willing to make them > > work at least in the worst fallback case. This patch must not change > > that meaning. These formats also must always work regardless of which > > GPU a client decides to use, but that is already implied by the > > compositor being able to import a dmabuf. The compositor does not need > > to try to factor in what other GPUs on the system might be able to > > render or not, that is for the client to figure out when it knows the > > formats the compositor can accept and is choosing a GPU to render with. > > It is theoretically possible that a client tries to use a GPU that > > cannot render any formats the compositor can use, but that is the > > client's
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
HI Daniel, Where can I find the work-in-progress implementation? I'd like to try it out with Broadcom driver which doesn't have implicit cross-process sync. I can add the explicit sync protocol implementation on the driver side but I'd need a reference to test it against. Cheers, Tomek On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone wrote: > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > > I can add that while pushing upstream, if there are no other changes > > coming. > > > > Reviewed-by: Pekka Paalanen > > > > You have ensured that the C files generated from this revision build > > fine in Weston, right? > > > > David, Daniel, since your name is in the maintainers, can I have your > > R-b, please? > > The protocol is: > Reviewed-by: Daniel Stone > > The Weston implementation looks pretty good so far, though there's no > full implementation of release yet. > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Monday, November 12, 2018 10:18 AM, Pekka Paalanen wrote: > On Sat, 10 Nov 2018 13:34:31 + > Simon Ser wrote: > > > On Monday, November 5, 2018 9:57 AM, Pekka Paalanen > > wrote: > > > > > Yeah. Another option is to send a wl_array of modifiers per format and > > > > > tranch. > > > > > > > > True. Any reason why this hasn't been done in the global? > > > > > > For formats? Well, it is simpler without a wl_array, and there might be > > > a lot of formats. > > > > > > Could there be a lot of modifiers per format? Would a wl_array make > > > anything easier? Just a thought. > > > > It's true that for this list of formats sorted by preference, we'll probably > > need to split modifiers anyway so I don't think we'd benefit a lot from this > > approach. > > Hi Simon, > > just to be clear, I was thinking of something like: > > event(uint format, wl_array(modifiers)) > > But I definitely do not insist on it if you don't see any obvious > benefits with it. Yeah. I think the benefits would not be substantial as we need to "split" these to order them by preference. So it would look like so: event(format1, wl_array(modifiers)) barrier() event(format1, wl_array(modifiers)) event(format2, wl_array(modifiers)) barrier() event(format1, wl_array(modifiers)) barrier() Also this is not consistent with the rest of the protocol. Maybe we can discuss this again for linux-dmabuf-unstable-v2. > It seems you and I made very different assumptions on how the hints > would be sent, I only realized it just now. More about that below. > > > > > > I suppose it will be enough to send tranches for just the currently > > > > > used format? Otherwise it could be "a lot" of data. > > > > > > > > What do you mean by "the currently used format"? > > > > > > This interface is used to send clients hints after they are already > > > presenting, which means they already have a format chosen and probably > > > want to stick with it, just changing the modifiers to be more optimal. > > > > If we only send the modifiers for the current format, how do clients tell > > the > > difference between the initial hints (which don't have a "currently used > > format") and the subsequent hints? > > I'm not sure I understand why they would need to see the difference. > But yes, I was short-sighted here and didn't consider the > initialization when a surface is not mapped yet. I didn't expect that > hints can be calculated if the surface is not mapped, but of course a > compositor can provide some defaults. I suppose the initial default > hints would boil down to what is most efficient to composite. > > > > > I expect clients to bind to this interface and create a surface hints > > > > object > > > > before the surface is mapped. In this case there's no "currently used > > > > format". > > > > > > Right, that's another use case. > > > > > > > It will be a fair amount of data, yes. However it's just a list of > > > > integers. > > > > When we send strings over the protocol (e.g. toplevel title in > > > > xdg-shell) it's > > > > about the same amount of data I guess. > > > > > > If the EGLConfig or GLXFBConfig or GLX visual lists are of any > > > indication... yes, they account for depth, stencil, aux, etc. but then > > > we will have modifiers. > > > > > > We already advertise the list of everything supported of format+modifer > > > in the linux_dmabuf extension. Could we somehow minimize the number of > > > recommended format+modifiers in hints? Or maybe that's not a concern > > > for the protocol spec? > > > > I'm not sure. > > > > After this patch, I'm not even sure how the formats+modifiers advertised by > > the > > global work. Are these formats+modifiers supported on the GPU the compositor > > uses for rendering? Intersection or union of formats+modifiers supported on > > all > > GPUs? > > The format+modifier advertised by the global before this patch are the > ones that can work at all, or the compositor is willing to make them > work at least in the worst fallback case. This patch must not change > that meaning. These formats also must always work regardless of which > GPU a client decides to use, but that is already implied by the > compositor being able to import a dmabuf. The compositor does not need > to try to factor in what other GPUs on the system might be able to > render or not, that is for the client to figure out when it knows the > formats the compositor can accept and is choosing a GPU to render with. > It is theoretically possible that a client tries to use a GPU that > cannot render any formats the compositor can use, but that is the > client's responsibility to figure out. Okay, that makes sense. And if a GPU doesn't support direct scan-out for some format+modifier, then it can always fallback to good ol' compositing. > So clearly the formats from the global can be used by a client at any > time. The hint formats OTOH has no reason to list absolutely > everything the compositor supports, but a
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Mon, 12 Nov 2018 10:13:39 + Simon Ser wrote: > On Monday, November 12, 2018 10:14 AM, Pekka Paalanen > wrote: > > > * Create a wl_surface, get the hints, and destroy everything (without > > > mapping > > > the surface) > > > * Allow the get_surface_hints to take a NULL surface > > > * Add a get_hints request without a wl_surface argument > > > * Forget about per-surface hints, make hints global > > > * (Someone else volunteers to patch Mesa to use per-surface FDs) > > > > > > What do you think? > > > > I think maybe it would be best to make the device hint "global" in a > > way, not tied to any surface, while leaving the format+modifier hints > > per-surface. IOW, just move the primary_device event from > > zwp_linux_dmabuf_device_hints_v1 into zwp_linux_dmabuf_v1 (or > > equivalent). > > > > Can anyone think of practical uses where the default device would need > > to depend on the surface somehow? > > > > I seem to recall we agreed that the primary device is the one the > > compositor is compositing with. Using the compositing device as the > > recommended default device makes sense from power consuption point of > > view: the compositor will be keeping that GPU awake anyway, so apps > > that don't care much about performance but do want to use a GPU should > > use it. > > In the case of compositing the surface, yes the primary device will be the one > used for compositing. However there are two cases in which a per-surface > device > hint would be useful. > > First, what happens if the surface isn't composited and is directly scanned > out? > Let's say I have two GPUs, with one output each. The compositor is using one > GPU > for compositing, and the surface is fullscreened on the other's output. If we > only have a global device hint, then the primary device will be the one used > for > compositing. However this causes an unnecessary copy between the two GPUs: the > client will render on one, and then the compositor will copy the DMA-BUF to > the > other one for scan-out. It would be better if the client can render directly > on > the GPU it will be scanned out with. Theoretically yes. However, apps are not usually prepared to switch the GPU they render with. Rendering with and being scanned out on are somewhat orthogonal. In the above case, the compositor could keep the default device as the compositing GPU, but change the modifiers so that it would be possible to import the dmabuf to the scanout GPU either for direct scanout or having the scanout GPU make the copy. It's not always possible for other reasons like an incompatible memory domain, I give you that. If you envision that apps (toolkits) might be willing to implement GPU switching sometimes, then I have no objections. It is again the difference between initial default hints vs. optimization hints after the surface is mapped. > Second, some compositors could support rendering with multiple GPUs. For > instance, if I have two GPUs with one output each, the compositor could use > GPU > 1 for compositing output 1 and GPU 2 for compositing output 2. In this case, > it > would be better if the client could render using the GPU it will be composited > with, and this depends on the output the surface is displayed on. From protocol point of view this does not differ from the first case. > > Your possible solutions are a valid list for another problem as well: > > the initial/default format+modifier hints before a surface is mapped. I > > think it should be either allowing get_surface_hints with NULL surface > > or adding get_default_hints request that doesn't take a surface. > > Technically the two equivalent. > > I think the cleanest solution would be to add get_default_hints, which would > create a wp_linux_dmabuf_hints object. Right. And if we want the preferred device to also have the initial hints vs. optimized hints after mapping, you'd keep the device event in zwp_linux_dmabuf_device_hints_v1. Sounds fine to me. Thanks, pq pgpAGWtByNcOx.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, Nov 09, 2018 at 04:24:56PM +0200, Alexandros Frantzis wrote: > On Fri, Nov 09, 2018 at 12:48:09PM +0200, Pekka Paalanen wrote: > > On Fri, 9 Nov 2018 09:46:36 +0200 > > Alexandros Frantzis wrote: > > > > > Signed-off-by: Alexandros Frantzis > > > > Hi Alf, > > Hi Pekka, > > thanks for the review! > > > could you come up with some rationale to put in the commit message on > > why this extension is being added? > > > > I can add that while pushing upstream, if there are no other changes > > coming. > > How about: > > This protocol enables explicit synchronization of asynchronous graphics > operations on buffers on a per-commit basis. Support is currently > limited to dmabuf buffers and dma_fence fence FDs. > > Explicit synchronization provides a more versatile notification > mechanism for buffer readiness and availability, and can be used to > improve efficiency by integrating with related functionality in display > and graphics APIs. > > Finally, the per-commit nature of the release events provided by this > protocol offer a solution to a deficiency of the wl_buffer.release event > (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). v2 of the text, with some more ChromeOS related information: This protocol enables explicit synchronization of asynchronous graphics operations on buffers on a per-commit basis. Support is currently limited to dmabuf buffers and dma_fence fence FDs. Explicit synchronization provides a more versatile notification mechanism for buffer readiness and availability, and can be used to improve efficiency by integrating with related functionality in display and graphics APIs. This protocol is also useful in ChromeOS ARC++ (running Android apps inside ChromeOS, using Wayland as the communication protocol), where it can enable integration of the ChromeOS compositor with the explicit synchronization mechanisms of the Android display subsystem. Finally, the per-commit nature of the release events provided by this protocol potentially offers a solution to a deficiency of the wl_buffer.release event (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > I can add that while pushing upstream, if there are no other changes > coming. > > Reviewed-by: Pekka Paalanen > > You have ensured that the C files generated from this revision build > fine in Weston, right? > > David, Daniel, since your name is in the maintainers, can I have your > R-b, please? The protocol is: Reviewed-by: Daniel Stone The Weston implementation looks pretty good so far, though there's no full implementation of release yet. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Monday, November 12, 2018 10:14 AM, Pekka Paalanen wrote: > > * Create a wl_surface, get the hints, and destroy everything (without > > mapping > > the surface) > > * Allow the get_surface_hints to take a NULL surface > > * Add a get_hints request without a wl_surface argument > > * Forget about per-surface hints, make hints global > > * (Someone else volunteers to patch Mesa to use per-surface FDs) > > > > What do you think? > > I think maybe it would be best to make the device hint "global" in a > way, not tied to any surface, while leaving the format+modifier hints > per-surface. IOW, just move the primary_device event from > zwp_linux_dmabuf_device_hints_v1 into zwp_linux_dmabuf_v1 (or > equivalent). > > Can anyone think of practical uses where the default device would need > to depend on the surface somehow? > > I seem to recall we agreed that the primary device is the one the > compositor is compositing with. Using the compositing device as the > recommended default device makes sense from power consuption point of > view: the compositor will be keeping that GPU awake anyway, so apps > that don't care much about performance but do want to use a GPU should > use it. In the case of compositing the surface, yes the primary device will be the one used for compositing. However there are two cases in which a per-surface device hint would be useful. First, what happens if the surface isn't composited and is directly scanned out? Let's say I have two GPUs, with one output each. The compositor is using one GPU for compositing, and the surface is fullscreened on the other's output. If we only have a global device hint, then the primary device will be the one used for compositing. However this causes an unnecessary copy between the two GPUs: the client will render on one, and then the compositor will copy the DMA-BUF to the other one for scan-out. It would be better if the client can render directly on the GPU it will be scanned out with. Second, some compositors could support rendering with multiple GPUs. For instance, if I have two GPUs with one output each, the compositor could use GPU 1 for compositing output 1 and GPU 2 for compositing output 2. In this case, it would be better if the client could render using the GPU it will be composited with, and this depends on the output the surface is displayed on. > Your possible solutions are a valid list for another problem as well: > the initial/default format+modifier hints before a surface is mapped. I > think it should be either allowing get_surface_hints with NULL surface > or adding get_default_hints request that doesn't take a surface. > Technically the two equivalent. I think the cleanest solution would be to add get_default_hints, which would create a wp_linux_dmabuf_hints object. > I do not like the temp wl_surface approach, and we really do want hints > to be per-surface because that's the whole point with the > format+modifier hints. Aye. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Sat, 10 Nov 2018 13:34:31 + Simon Ser wrote: > On Monday, November 5, 2018 9:57 AM, Pekka Paalanen > wrote: > > > > Yeah. Another option is to send a wl_array of modifiers per format and > > > > tranch. > > > > > > True. Any reason why this hasn't been done in the global? > > > > For formats? Well, it is simpler without a wl_array, and there might be > > a lot of formats. > > > > Could there be a lot of modifiers per format? Would a wl_array make > > anything easier? Just a thought. > > It's true that for this list of formats sorted by preference, we'll probably > need to split modifiers anyway so I don't think we'd benefit a lot from this > approach. Hi Simon, just to be clear, I was thinking of something like: event(uint format, wl_array(modifiers)) But I definitely do not insist on it if you don't see any obvious benefits with it. It seems you and I made very different assumptions on how the hints would be sent, I only realized it just now. More about that below. > > > > I suppose it will be enough to send tranches for just the currently > > > > used format? Otherwise it could be "a lot" of data. > > > > > > What do you mean by "the currently used format"? > > > > This interface is used to send clients hints after they are already > > presenting, which means they already have a format chosen and probably > > want to stick with it, just changing the modifiers to be more optimal. > > If we only send the modifiers for the current format, how do clients tell the > difference between the initial hints (which don't have a "currently used > format") and the subsequent hints? I'm not sure I understand why they would need to see the difference. But yes, I was short-sighted here and didn't consider the initialization when a surface is not mapped yet. I didn't expect that hints can be calculated if the surface is not mapped, but of course a compositor can provide some defaults. I suppose the initial default hints would boil down to what is most efficient to composite. > > > I expect clients to bind to this interface and create a surface hints > > > object > > > before the surface is mapped. In this case there's no "currently used > > > format". > > > > Right, that's another use case. > > > > > It will be a fair amount of data, yes. However it's just a list of > > > integers. > > > When we send strings over the protocol (e.g. toplevel title in xdg-shell) > > > it's > > > about the same amount of data I guess. > > > > If the EGLConfig or GLXFBConfig or GLX visual lists are of any > > indication... yes, they account for depth, stencil, aux, etc. but then > > we will have modifiers. > > > > We already advertise the list of everything supported of format+modifer > > in the linux_dmabuf extension. Could we somehow minimize the number of > > recommended format+modifiers in hints? Or maybe that's not a concern > > for the protocol spec? > > I'm not sure. > > After this patch, I'm not even sure how the formats+modifiers advertised by > the > global work. Are these formats+modifiers supported on the GPU the compositor > uses for rendering? Intersection or union of formats+modifiers supported on > all > GPUs? The format+modifier advertised by the global before this patch are the ones that can work at all, or the compositor is willing to make them work at least in the worst fallback case. This patch must not change that meaning. These formats also must always work regardless of which GPU a client decides to use, but that is already implied by the compositor being able to import a dmabuf. The compositor does not need to try to factor in what other GPUs on the system might be able to render or not, that is for the client to figure out when it knows the formats the compositor can accept and is choosing a GPU to render with. It is theoretically possible that a client tries to use a GPU that cannot render any formats the compositor can use, but that is the client's responsibility to figure out. So clearly the formats from the global can be used by a client at any time. The hint formats OTOH has no reason to list absolutely everything the compositor supports, but a compositor can choose on its own judgement to send only a sub-set it would prefer. However, after a client has picked a format and used it, then there should be hints with that format, at least if they can make any difference. I'm not sure. Not listing everything always was my intuitive assumption, and I believe you perhaps assumed the opposite so that a client has absolutely all the information to e.g. optimize the modifier of a format that the compositor would not prefer at all even though it does work. It would be simpler to always send everything, but that will be much more protocol traffic. Would it be too much? I don't know, could you calculate some examples of how many bytes a typical hints update would be if sending everything always? Thanks, pq pgp5TMa0hmmup.pgp Description: OpenPGP digital signature
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Sat, 10 Nov 2018 13:54:19 + Simon Ser wrote: > Just a general update about this: I tried to see how we could make Mesa use > this > new protocol. > > A bad news is that the DRM FD is per-EGLDisplay and I think it would require > quite some changes to make it per-EGLSurface. I'm still new to the Mesa > codebase, so it'd probably make sense to only use the new protocol to get the > device FD, without relying on wl_drm anymore. We could talk about using the > protocol more efficiently in the future. I also think a lot of clients weren't > designed to support multiple device FDs, so it would be nice to have a > smoother > upgrade path. Hi, yeah, that sounds fine to me: use the new protocol, if available, to only find the default device at EGLDisplay creation. What can be done per surface later is only the changing of format+modifier, within the limits of what EGLConfig the app is using, so maybe it's the modifier alone. If EGL should do that automatically and internally to begin with... it could change the modifier at least. > That leaves an issue: the whole protocol provides hints for a surface. When > the > EGLDisplay is created we don't have a surface yet. I can think of a few > possible > solutions: Indeed. > > * Create a wl_surface, get the hints, and destroy everything (without mapping > the surface) > * Allow the get_surface_hints to take a NULL surface > * Add a get_hints request without a wl_surface argument > * Forget about per-surface hints, make hints global > * (Someone else volunteers to patch Mesa to use per-surface FDs) > > What do you think? I think maybe it would be best to make the device hint "global" in a way, not tied to any surface, while leaving the format+modifier hints per-surface. IOW, just move the primary_device event from zwp_linux_dmabuf_device_hints_v1 into zwp_linux_dmabuf_v1 (or equivalent). Can anyone think of practical uses where the default device would need to depend on the surface somehow? I seem to recall we agreed that the primary device is the one the compositor is compositing with. Using the compositing device as the recommended default device makes sense from power consuption point of view: the compositor will be keeping that GPU awake anyway, so apps that don't care much about performance but do want to use a GPU should use it. Your possible solutions are a valid list for another problem as well: the initial/default format+modifier hints before a surface is mapped. I think it should be either allowing get_surface_hints with NULL surface or adding get_default_hints request that doesn't take a surface. Technically the two equivalent. I do not like the temp wl_surface approach, and we really do want hints to be per-surface because that's the whole point with the format+modifier hints. Thanks, pq pgprQJZfcbKNR.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
