Re: DMAbuf flickering from three different sources
Thanks, I'll continue to give a look. Best Matteo Valdina On Thu, Oct 4, 2018, 06:29 Pekka Paalanen wrote: > On Thu, 4 Oct 2018 05:59:14 -0500 > Matteo Valdina wrote: > > > Hi Pekka, > > No the problem is also present on weston 4.0 and 5.0. > > > > One interesting note, all sources use the same resolution (4K and > GStreamer > > is using format NV12). > > The two gstreamer sources are in full screen in two different display. > > Sorry, I have no idea. I did get a thought about a patch in master, but > then saw it was from you. :-) > > Maybe it could be some state mixup around the YUV texturing in > GL-renderer, I would assume that to be rarely tested, especially with > multiple simultaneous clients hitting it. > > > Thanks, > pq > > > On Thu, Oct 4, 2018, 05:44 Pekka Paalanen wrote: > > > > > On Wed, 3 Oct 2018 11:19:28 -0500 > > > Matteo Valdina wrote: > > > > > > > Hi Y'all, > > > > > > > > I'm working in a Weston-based compositor (4.0 and later on the 5.0) > and I > > > > faced an issue. > > > > > > > > I have two different sources (1 QT application and 2 GStreamer > > > waylandsink) > > > > that provide content a live stream using the > linux-dmabuf-unstable-v1. > > > > The issue is that the frames of this three sources are displayed in > > > > randomly on all these sources. > > > > > > > > I mean that source 1 display some frame for source 1 and some frame > from > > > > source 2 or 3. And this is affecting multiple processes (the QT > > > application > > > > is a different process). > > > > > > > > It looks like the same DMAbuf pool is shared across all applications. > > > > > > > > This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 > and on > > > > an Intel HD graphics 610. > > > > > > > > Any suggestions to tackle this? > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols] input-method: Add zwp-input-method-v2
This protocol is based on v1, current text-input-v3, and wl_keyboard version 6. The pieces passing data relevant to the application on the other side of the compositor are a mirror copy of text-input-v3 events and requests. Compared to input-method-v1: - assumes that once preedit is displayed, no selection can be active, removing some selection handling - follow text-input and removes language indicators - explicitly attaches to seats - removes "commit" text which would replace the preedit string automatically in case it wasn't "confirmed" (whatever it means) - adds double-buffering in the same places as text-input-v3 - drops input_method_context and places its functionality directly in input_method - removes the ability to move the cursor position outside of preedit. It still allows to delete a larger chunk of text and replace it with a preedit - doesn't allow for sending of keyboard events to the compositor - doesn't define any surfaces except for a special compositor-positioned popup --- Hi, continuing the RFC, I think this protocol is actually workable now, and I'm sending this with the PATCH qualifier. The practical verification came in the form of a partial wlroots implementation [0]. The formal issues (chiefly stemming from copy-pasting things at night) have been pointed out to me by Simon, and corrected. The major unverified parts are keyboard grabs and popup surfaces, which I will verify next. Changes compared to the RFC: - fixed so many confusing typos - renamed preedit_text request to set_preedit_text - described what happens when things get destroyed - defined the role of input_popup sorface and forbade it from being deleted - copied wl_keyboard to serve as the keyboard grab interface I hope you can help me find the remaining issues and turn this interface into reality! Cheers, Dorota Czaplejewicz Makefile.am| 1 + unstable/input-method/input-method-unstable-v2.xml | 490 + 2 files changed, 491 insertions(+) create mode 100644 unstable/input-method/input-method-unstable-v2.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..f3b9f80 100644 --- a/Makefile.am +++ b/Makefile.am @@ -7,6 +7,7 @@ unstable_protocols = \ unstable/text-input/text-input-unstable-v1.xml \ unstable/text-input/text-input-unstable-v3.xml \ unstable/input-method/input-method-unstable-v1.xml \ + unstable/input-method/input-method-unstable-v2.xml \ unstable/xdg-shell/xdg-shell-unstable-v5.xml \ unstable/xdg-shell/xdg-shell-unstable-v6.xml \ unstable/relative-pointer/relative-pointer-unstable-v1.xml \ diff --git a/unstable/input-method/input-method-unstable-v2.xml b/unstable/input-method/input-method-unstable-v2.xml new file mode 100644 index 000..62be9d9 --- /dev/null +++ b/unstable/input-method/input-method-unstable-v2.xml @@ -0,0 +1,490 @@ + + + + +Copyright © 2008-2011 Kristian Høgsberg +Copyright © 2010-2011 Intel Corporation +Copyright © 2012-2013 Collabora, Ltd. +Copyright © 2012, 2013 Intel Corporation +Copyright © 2015, 2016 Jan Arne Petersen +Copyright © 2017, 2018 Red Hat, Inc. +Copyright © 2018 Purism SPC + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol allows applications to act as input methods for compositors. + +An input method context is used to manage the state of the input method. + +Text strings are UTF-8 encoded, their indices and lengths are in bytes. + +This document adheres to the RFC 2119 when using words like "must", +"should", "may", etc. + +Warning! The protocol described in this f
Re: [RFC wayland-protocols] input-method: Add zwp-input-method-v2
Thank you Simon for reading the proposal so carefully! My replies are inline. On Fri, 07 Sep 2018 11:54:36 + Simon Ser wrote: > On 6 August 2018 3:00 PM, Dorota Czaplejewicz > wrote: > > This protocol is based on v1, and current text-input-v3. > > > > The pieces passing data relevant to the application on the other side of the > > compositor are a mirror copy of text-input-v3 events and requests. > > > > Compared to input-method-v1: > > - assumes that once preedit is displayed, no selection can be active, > > removing > > some selection handling > > - follow text-input and removes language indicators > > - explicitly attaches to seats > > - removes "commit" text which would replace the preedit string automatically > > in case it wasn't "confirmed" (whatever it means) > > - adds double-buffering in the same places as text-input-v3 > > - drops input_method_context and places its functionality directly in > > input_method > > - removes the ability to move the cursor position outside of preedit. It > > still > > allows to delete a larger chunk of text and replace it with a preedit > > - doesn't allow for sending of keyboard events to the compositor > > - Doesn't define any surfaces except for a special compositor-positioned > > popup > > --- > > Hi, > > > > the third item on the path to well-supported virtual keyboard experience > > under > > Wayland comes from Purism. This one allows the compositor to delegate text > > input and composition duties to an application instead of handling it > > itself. > > Input-method-delegating compositor would typically become only a broker > > between the input method client and other applications. > > > > I took the existing input-method protocol, and after dissecting it with the > > help of wlroots developers, I came up with an improved version, which is > > attached for your (re)viewing pleasure. > > > > A large part of this protocol was taken from recent text-input-v3, and some > > description text was improved. Still, the protocol has a couple of rough > > edges, which is why it's titled RFC and not a patch. > > > > The issues I have had most trouble with are related to the handling of > > keyboard grabs. These are meant to allow traditional, keyboard-based input > > methods, to take over keyboard input in order to compose text in a different > > way. > > > > First, keyboard grabs are defined as unreliable. I'm not sure whether this > > is > > the right choice, but given that making them more reliable seems rather > > complicated, this is the default one. > > > > In addition, handling the keyboard events themselves is troublesome, because > > an input method, even if it has a surface, is not meant to have keyboard > > focus > > while it's in operation. Returning wl_keyboard as new_id seems not to be > > possible due to versioning. Should the request make an existing wl_keyboard > > instance change behaviour? Or perhaps there should be a new > > zwp_input_method_keyboard mimicking the wl_keyboard interface? > > > > I'm interested in your opinions. > > > > Thank you, > > Dorota Czaplejewicz > > Thansk for your RFC! > > > Makefile.am| 1 + > > unstable/input-method/input-method-unstable-v2.xml | 403 > > + > > 2 files changed, 404 insertions(+) > > create mode 100644 unstable/input-method/input-method-unstable-v2.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 6394e26..f3b9f80 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -7,6 +7,7 @@ unstable_protocols = > > \ > > unstable/text-input/text-input-unstable-v1.xml > > \ > > unstable/text-input/text-input-unstable-v3.xml > > \ > > unstable/input-method/input-method-unstable-v1.xml > > \ > > + unstable/input-method/input-method-unstable-v2.xml > > \ > > unstable/xdg-shell/xdg-shell-unstable-v5.xml > > \ > > unstable/xdg-shell/xdg-shell-unstable-v6.xml > > \ > > unstable/relative-pointer/relative-pointer-unstable-v1.xml > > \ > > diff --git a/unstable/input-method/input-method-unstable-v2.xml > > b/unstable/input-method/input-method-unstable-v2.xml > > new file mode 100644 > > index 000..8cf8e29 > > --- /dev/null > > +++ b/unstable/input-method/input-method-unstable-v2.xml > > @@ -0,0 +1,403 @@ > > + > > + > > + > > + > > +Copyright © 2012, 2013 Intel Corporation > > +Copyright © 2015, 2016 Jan Arne Petersen > > +Copyright © 2017, 2018 Red Hat, Inc. > > +Copyright © 2018 Purism SPC > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software and associated documentation files (the > > "Software"), > > +to deal in the Software without restriction, including without > > li
Re: DMAbuf flickering from three different sources
On Thu, 4 Oct 2018 05:59:14 -0500 Matteo Valdina wrote: > Hi Pekka, > No the problem is also present on weston 4.0 and 5.0. > > One interesting note, all sources use the same resolution (4K and GStreamer > is using format NV12). > The two gstreamer sources are in full screen in two different display. Sorry, I have no idea. I did get a thought about a patch in master, but then saw it was from you. :-) Maybe it could be some state mixup around the YUV texturing in GL-renderer, I would assume that to be rarely tested, especially with multiple simultaneous clients hitting it. Thanks, pq > On Thu, Oct 4, 2018, 05:44 Pekka Paalanen wrote: > > > On Wed, 3 Oct 2018 11:19:28 -0500 > > Matteo Valdina wrote: > > > > > Hi Y'all, > > > > > > I'm working in a Weston-based compositor (4.0 and later on the 5.0) and I > > > faced an issue. > > > > > > I have two different sources (1 QT application and 2 GStreamer > > waylandsink) > > > that provide content a live stream using the linux-dmabuf-unstable-v1. > > > The issue is that the frames of this three sources are displayed in > > > randomly on all these sources. > > > > > > I mean that source 1 display some frame for source 1 and some frame from > > > source 2 or 3. And this is affecting multiple processes (the QT > > application > > > is a different process). > > > > > > It looks like the same DMAbuf pool is shared across all applications. > > > > > > This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 and on > > > an Intel HD graphics 610. > > > > > > Any suggestions to tackle this? pgpfofs8ZAtv5.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: DMAbuf flickering from three different sources
Hi Pekka, No the problem is also present on weston 4.0 and 5.0. One interesting note, all sources use the same resolution (4K and GStreamer is using format NV12). The two gstreamer sources are in full screen in two different display. Best Matteo Valdina On Thu, Oct 4, 2018, 05:44 Pekka Paalanen wrote: > On Wed, 3 Oct 2018 11:19:28 -0500 > Matteo Valdina wrote: > > > Hi Y'all, > > > > I'm working in a Weston-based compositor (4.0 and later on the 5.0) and I > > faced an issue. > > > > I have two different sources (1 QT application and 2 GStreamer > waylandsink) > > that provide content a live stream using the linux-dmabuf-unstable-v1. > > The issue is that the frames of this three sources are displayed in > > randomly on all these sources. > > > > I mean that source 1 display some frame for source 1 and some frame from > > source 2 or 3. And this is affecting multiple processes (the QT > application > > is a different process). > > > > It looks like the same DMAbuf pool is shared across all applications. > > > > This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 and on > > an Intel HD graphics 610. > > > > Any suggestions to tackle this? > > Hi, > > is this problem only on your own compositor, while upstream Weston > works fine? > > How different is your compositor from Weston, what have you modified? > > I can't imagine what kind of bug in the compositor could cause mixing > up buffers from different clients at the dmabuf level. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: DMAbuf flickering from three different sources
On Wed, 3 Oct 2018 11:19:28 -0500 Matteo Valdina wrote: > Hi Y'all, > > I'm working in a Weston-based compositor (4.0 and later on the 5.0) and I > faced an issue. > > I have two different sources (1 QT application and 2 GStreamer waylandsink) > that provide content a live stream using the linux-dmabuf-unstable-v1. > The issue is that the frames of this three sources are displayed in > randomly on all these sources. > > I mean that source 1 display some frame for source 1 and some frame from > source 2 or 3. And this is affecting multiple processes (the QT application > is a different process). > > It looks like the same DMAbuf pool is shared across all applications. > > This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 and on > an Intel HD graphics 610. > > Any suggestions to tackle this? Hi, is this problem only on your own compositor, while upstream Weston works fine? How different is your compositor from Weston, what have you modified? I can't imagine what kind of bug in the compositor could cause mixing up buffers from different clients at the dmabuf level. Thanks, pq pgpF3nQ2wbXaH.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 v2] unstable: add primary-selection protocol
On Sun, Sep 23, 2018 at 10:52:34AM +, Simon Ser wrote: > From: emersion > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to its Wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Simon Ser Reviewed-by: Jonas Ådahl with one minor nit below. I'd prefer to get another RB or Ack (by Carlos eg) before landing. > --- > > Changes from v1 to v2: renamed with the wp_ prefix > > Makefile.am | 3 +- > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 226 ++ > 3 files changed, 232 insertions(+), 1 deletion(-) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..aca32c2 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -20,7 +20,8 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ Accidental change (tabs -> spaces) above. Jonas > + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..ae0a402 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Simon Ser > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..749dd86 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,226 @@ > + > + > + > +Copyright © 2015, 2016 Red Hat > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > +This protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +wp_primary_selection_offer objects are first announced through the > +wp_primary_selection_device.data_offer event. Immediately after this > event, > +the primary data offer will emit wp_primary_selection_offer.offer events > +to let know of the mime types being offered. > + > +When the primary selection changes, the client with the keyboard focus > +will receive wp_primary_selection_device.selection events. Only the > client > +with the keyboard focus will receive such events with a non-NULL > +wp_primary_selection
Re: External DMA to gpu
On Thu, 4 Oct 2018 10:15:52 +0200 Dirk Eibach wrote: > Hi Pekka, > > > > > I suppose that means you still do a copy from the gbm_bo/dmabuf into a > > > > window surface? If you used zwp_linux_dmabuf manually from your Wayland > > > > client, you could avoid even that copy. It has the same caveat as below > > > > though. > > > > > > I don't think so. The grabber does direct DMA to the VRAM, making the > > > texture should be zero copy. Or am I missing something? > > > > Below you say you use glEGLImageTargetTexture2DOES(). That gets you a > > GL texture. To actually get that GL texture on screen, you have to do a > > GL drawing command to copy the pixels into an EGLSurface created from a > > wl_surface. That's the copy I'm referring to and which would be > > avoidable if you don't have to e.g. convert the color format in the app. > > > > Or are you using some other tricks? > > > > Once the pixels are on a wl_surface, the compositor will do one more > > copy to get those into a framebuffer, unless the requirements for > > scanning out directly from the client buffer are met. But I would guess > > it is more important to optimize the grabber-to-VRAM path than the > > wl_surface-to-scanout path which is likely just VRAM-to-VRAM so pretty > > good already. > > If I have to use a shader for colorspace conversion I cannot use this > approach, right? Sorry, which "this"? If you use a shader in your app, you are making a copy, and you need to use glEGLImageTargetTexture2DOES() to make the grabbed buffer available to the shader. So yes, in that case you don't use zwp_linux_dmabuf directly but you rely on EGL instead to send your final image to the compositor. If instead you're asking about what the compositor does, then the scanout-ability on the client side is determined how the EGL implementation chooses to allocate the buffer it will send to the compositor. Often it is scanout-able, so you don't lose that opportunity. > > > > > My only problem left is that glEGLImageTargetTexture2DOES() does only > > > > > accept ARGB and not RGB888, which means I have to waste a lot of > > > > > PCIe bandwidth. Any ideas how to get around this? Or what would be a > > > > > more appropriate place to post this question? > > > > > > > > Yeah, I suppose support for true 24-bit-storage formats is rare > > > > nowadays. > > > > > > > > The format list advertised via zwp_linux_dmabuf, visible via e.g. > > > > weston-info, can tell you what you could use directly. After all, a > > > > Wayland compositor does the same EGLImage import as you do in the > > > > simple case. > > > > > > > > You could probably use the GPU to convert from 24-bit to 32-bit format > > > > though, by importing the image as R8 format instead of RGB888 and > > > > pretend the width is 3x. Then you could use a fragment shader to sample > > > > the real R, G and B separately and write out a 32-bit format image for > > > > display. > > > > > > Is there any example code for a gl noob? I already did some research but > > > didn't find anything useful. > > > > Nothing much come to mind. Weston uses similar tricks to convert YUV > > data to RGB by lying to EGL and GL that the incoming buffer is R8 or > > RG88 and using a fragment shader to compute the proper RGB values. It > > is really just about lying to EGL when you import the dmabuf: instead of > > the actual pixel format, you use R8 and adjust the width/height/stride > > to match so that you can sample each byte correctly. Then in the > > fragment shader, you compute the correct texture coordinates to read > > each of R, G and B values for an output pixel and then combine those > > into an output color. > > > > Reading YUV is more tricky than reading 24-bit RGB, because YUV is > > usually arranged in multiple planes, some of which are sub-sampled, > > e.g. half resolution. > > Thanks, that was very helpful, as always. This is what we came up > with, and it works nicely: > float x_int = floor(3840.0 * vTexCoord.x) * 3.0;\n" > float r = texture2D(uTexture, vec2((x_int + 0.0) / (3840.0 * 3.0), > vTexCoord.y)).r; > float g = texture2D(uTexture, vec2((x_int + 1.0) / (3840.0 * 3.0), > vTexCoord.y)).r; > float b = texture2D(uTexture, vec2((x_int + 2.0) / (3840.0 * 3.0), > vTexCoord.y)).r; > gl_FragColor = vec4(r, g, b, 1.0);// add alpha component > > We have to pass the horizontal resolution to the shader, I suppose > there is no way around this, right? Correct. I wonder if if you should add 0.5 to x_int to hit the middle of the texel, just to be sure NEAREST interpolation gives you the right texel. I'd have to draw it on paper to see if that formula is exactly right, so can't say off-hand. > I was afraid that the unaligned access in the shader would have some > performace penalty. But in fact performace is better than the 32-bit > version. Thumbs up! Nice! Thanks, pq pgpvS3oRZqX93.pgp Description: OpenPGP digital signature __
Re: External DMA to gpu
Hi Pekka, > > > I suppose that means you still do a copy from the gbm_bo/dmabuf into a > > > window surface? If you used zwp_linux_dmabuf manually from your Wayland > > > client, you could avoid even that copy. It has the same caveat as below > > > though. > > > > I don't think so. The grabber does direct DMA to the VRAM, making the > > texture should be zero copy. Or am I missing something? > > Below you say you use glEGLImageTargetTexture2DOES(). That gets you a > GL texture. To actually get that GL texture on screen, you have to do a > GL drawing command to copy the pixels into an EGLSurface created from a > wl_surface. That's the copy I'm referring to and which would be > avoidable if you don't have to e.g. convert the color format in the app. > > Or are you using some other tricks? > > Once the pixels are on a wl_surface, the compositor will do one more > copy to get those into a framebuffer, unless the requirements for > scanning out directly from the client buffer are met. But I would guess > it is more important to optimize the grabber-to-VRAM path than the > wl_surface-to-scanout path which is likely just VRAM-to-VRAM so pretty > good already. If I have to use a shader for colorspace conversion I cannot use this approach, right? > > > > My only problem left is that glEGLImageTargetTexture2DOES() does only > > > > accept ARGB and not RGB888, which means I have to waste a lot of > > > > PCIe bandwidth. Any ideas how to get around this? Or what would be a > > > > more appropriate place to post this question? > > > > > > Yeah, I suppose support for true 24-bit-storage formats is rare > > > nowadays. > > > > > > The format list advertised via zwp_linux_dmabuf, visible via e.g. > > > weston-info, can tell you what you could use directly. After all, a > > > Wayland compositor does the same EGLImage import as you do in the > > > simple case. > > > > > > You could probably use the GPU to convert from 24-bit to 32-bit format > > > though, by importing the image as R8 format instead of RGB888 and > > > pretend the width is 3x. Then you could use a fragment shader to sample > > > the real R, G and B separately and write out a 32-bit format image for > > > display. > > > > Is there any example code for a gl noob? I already did some research but > > didn't find anything useful. > > Nothing much come to mind. Weston uses similar tricks to convert YUV > data to RGB by lying to EGL and GL that the incoming buffer is R8 or > RG88 and using a fragment shader to compute the proper RGB values. It > is really just about lying to EGL when you import the dmabuf: instead of > the actual pixel format, you use R8 and adjust the width/height/stride > to match so that you can sample each byte correctly. Then in the > fragment shader, you compute the correct texture coordinates to read > each of R, G and B values for an output pixel and then combine those > into an output color. > > Reading YUV is more tricky than reading 24-bit RGB, because YUV is > usually arranged in multiple planes, some of which are sub-sampled, > e.g. half resolution. Thanks, that was very helpful, as always. This is what we came up with, and it works nicely: float x_int = floor(3840.0 * vTexCoord.x) * 3.0;\n" float r = texture2D(uTexture, vec2((x_int + 0.0) / (3840.0 * 3.0), vTexCoord.y)).r; float g = texture2D(uTexture, vec2((x_int + 1.0) / (3840.0 * 3.0), vTexCoord.y)).r; float b = texture2D(uTexture, vec2((x_int + 2.0) / (3840.0 * 3.0), vTexCoord.y)).r; gl_FragColor = vec4(r, g, b, 1.0);// add alpha component We have to pass the horizontal resolution to the shader, I suppose there is no way around this, right? I was afraid that the unaligned access in the shader would have some performace penalty. But in fact performace is better than the 32-bit version. Thumbs up! Cheers Dirk ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
