Re: Fbdev-backend removal from Weston (Re: Upcoming release)
On Wednesday, January 23, 2019 4:09:44 AM EST Pekka Paalanen wrote: > On Tue, 22 Jan 2019 22:46:02 -0500 > nerdopolis wrote: > > > On Tuesday, January 22, 2019 9:55:15 AM EST Pekka Paalanen wrote: > > > > > > > On Tue, 22 Jan 2019 10:17:32 +0200 > > > Pekka Paalanen wrote: > > > > > > > Hi, > > > > > > > > do you actually have a use case for that? It's ok if you do, we can > > > > keep it around for some more, but the simple fact that some hardware > > > > exists that does not have a working DRM driver is not enough. There > > > > should be users too. > > > > > > > > The fbdev-backend certainly has its shortcomings, and I don't mean just > > > > the lack of multi-output or monitor hotplug or GPU acceleration or > > > > tearing or timings based on nothing but timers; I recall VT-switching > > > > being broken for years now, and it doesn't (cannot?) use logind to open > > > > the FB devices. Did I forget some? > > > > > Hi > > > > Well, TBH, It's just my quazi-distribution Live CD that I still maintain... > > It falls back to the Framebuffer on systems (or seats) that don't have > > Kernel Mode Setting. The number of users now probably is low... > > Right. Would you be able to do a test? Disable fbdev on your distro and > see if anyone complains? > TBH, the user base is likely not as high as it was in 2012. It's prime focus was to allow users to test anything Wayland live. So I don't think that would be a good way to tell, since now there are other more popular ways people have been using it now. > In fact, would be nice if all distributions did that test. I'm not in > that much hurry to delete the backend yet. > > > VT switching works great. It works without weston-launch, and I can switch > > away > > to a second instance of Weston using the Framebuffer, without them stepping > > on > > each other, and I can switch back to the original one, and it continues > > working > > > > I do have to create a udev file that sets > > SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess" > > though... > > Yes, that rule or similar is required because logind does not deal fb > devices IIRC and Weston certainly doesn't ask. > > Are you relying on logind or running Weston privileged to have VT > switching working? > I am making no changes to logind. I am not running Weston as root. I am not even granting the plugdev group access to the /dev/fbX devices (It's a "hidden" boot option, disabled by default). Just systemd-run that starts it as a User account. > It's been a long time since I tried VT-switching with fbdev, but it > didn't work with logind back then: > https://gitlab.freedesktop.org/wayland/weston/issues/78 > Could it have been fixed in logind instead? > Yeah, I wasnt even aware of that one. It was probably logind. Weston is working fine. I can switch between the framebuffer backed login greeter, and a frame buffer backed login session, and they don't draw on each other. Weston even logs when the session becomes active and inactive, so it is aware. It even works on seats that do NOT have TTYs, since my login manager is multiseat aware now, I can test that :) > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fbdev-backend removal from Weston (Re: Upcoming release)
On Tue, 22 Jan 2019 10:17:32 +0200 Pekka Paalanen wrote: keep it around for some more, but the simple fact that some hardware exists that does not have a working DRM driver is not enough Fbdev worked out of the box on my Bay Trail system, but DRM kept freezing where only SysRq helped. It seems an issue in Mesa, downgrade to 18.1.9 and exporting WESTON_DISABLE_ATOMIC=y works, but I haven't been able to track and report, because nothing weird got in the logs. By all means delete this backend if it's tech debt, though some users are there yet. Looking forward to new releases so I can unmask >=media-video/mpv-0.29, which wants xdg_wm_base. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Should Weston wait for client buffers to finish rendering?
Hello Satyeshwar, nice to hear from you again (: short answer to your question: there is already implementation which is doing what you are asking: https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 From: wayland-devel On Behalf Of Singh, Satyeshwar Sent: Mittwoch, 23. Januar 2019 19:44 To: wayland-devel@lists.freedesktop.org Subject: Should Weston wait for client buffers to finish rendering? Hey guys, As you know, Weston doesn't wait for client buffers to finish rendering. That is typically left as an exercise for the kernel mode graphics driver. I am wondering if anyone knows why this policy decision was made? More importantly, is there any harm (or any side effect) that I am not thinking of if this policy were to change such that the compositor indeed started waiting for client buffers to finish rendering first and only used those buffers for composition that had finished? Imagine a benchmark case where the client renders for example 800 frames and attaches their buffer ids to a surface, the compositor uses the last one that came in before its repaint cycle started for composition and display on the screen. This buffer may not have been rendered by the GPU yet because it is working on previous buffers. However, it may not finish before the next Vblank and if it doesn't finish, then the compositor's scan out buffer also isn't going to be displayed by the kernel driver. If we change the policy for the compositor to always use the last finished buffer, then at least the compositor's scan out buffer will be displayed for the next Vblank even if it's not showing the last frame from the client. Thoughts? -Satyeshwar ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Should Weston wait for client buffers to finish rendering?
Hey guys, As you know, Weston doesn't wait for client buffers to finish rendering. That is typically left as an exercise for the kernel mode graphics driver. I am wondering if anyone knows why this policy decision was made? More importantly, is there any harm (or any side effect) that I am not thinking of if this policy were to change such that the compositor indeed started waiting for client buffers to finish rendering first and only used those buffers for composition that had finished? Imagine a benchmark case where the client renders for example 800 frames and attaches their buffer ids to a surface, the compositor uses the last one that came in before its repaint cycle started for composition and display on the screen. This buffer may not have been rendered by the GPU yet because it is working on previous buffers. However, it may not finish before the next Vblank and if it doesn't finish, then the compositor's scan out buffer also isn't going to be displayed by the kernel driver. If we change the policy for the compositor to always use the last finished buffer, then at least the compositor's scan out buffer will be displayed for the next Vblank even if it's not showing the last frame from the client. Thoughts? -Satyeshwar ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fbdev-backend removal from Weston (Re: Upcoming release)
On Tue, 2019-01-22 at 22:46 -0500, nerdopolis wrote: > Well, TBH, It's just my quazi-distribution Live CD that I still maintain... > It falls back to the Framebuffer on systems (or seats) that don't have > Kernel Mode Setting. The number of users now probably is low... I think the biggest class of fbdev users on reasonably modern hardware are people who've said nomodeset to avoid a drm driver bug and so fall down to efifb. I wonder if it's worth making a trivial efikms driver for that case. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/3] client: Add wl_display_soft_flush()
On Fri, 7 Sep 2018 18:14:04 -0700
Lloyd Pique wrote:
> This allows a client to occasionally flush the output buffers in the
> middle of making a large number of calls which fill them.
>
> A soft flush differs from a normal flush in that the buffer is not
> flushed if it is not full enough. The current criteria set is the buffer
> being half full.
>
> This does not completely replace the need to call wl_display_flush(),
> which ensures all the output is actually sent. However the client can
> make this call to properly handle any send errors that might occur.
>
> Includes a test to make sure that it can be used in a situation where a
> flush is needed and would return an EAGAIN, which would normally
> set a fatal display error if the core-client tried to do an internal
> flush if the output buffer became completely full.
>
> Signed-off-by: Lloyd Pique
> ---
> src/connection.c | 30 ++-
> src/wayland-client-core.h | 3 ++
> src/wayland-client.c | 77 +--
> src/wayland-private.h | 2 +-
> src/wayland-server.c | 6 +--
> tests/connection-test.c | 10 ++---
> tests/display-test.c | 62 +++
> tests/os-wrappers-test.c | 2 +-
> 8 files changed, 161 insertions(+), 31 deletions(-)
>
Hi Lloyd,
it seems the main justification for this patch is to avoid the overhead
of calling wl_display_flush() very often. Would you happen to have any
benchmark numbers on wl_display_flush() vs. wl_display_soft_flush()
from a real use case?
That would be very good to have in the commit message.
This patch does not compile:
/home/pq/git/wayland/src/connection.c: In function ‘wl_connection_write’:
/home/pq/git/wayland/src/connection.c:410:7: error: too few arguments to
function ‘wl_connection_flush’
if (wl_connection_flush(connection) < 0)
/home/pq/git/wayland/src/connection.c: In function ‘wl_connection_put_fd’:
/home/pq/git/wayland/src/connection.c:460:7: error: too few arguments to
function ‘wl_connection_flush’
if (wl_connection_flush(connection) < 0)
> diff --git a/src/connection.c b/src/connection.c
> index f965210..c271fa0 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -285,8 +285,31 @@ decode_cmsg(struct wl_buffer *buffer, struct msghdr *msg)
> return 0;
> }
>
> +static int
Always use bool for booleans, especially for predicates like this.
> +wl_buffer_is_half_full(struct wl_buffer *b)
> +{
> + return wl_buffer_size(b) > sizeof(b->data) / 2;
> +}
> +
> +static int
> +wl_fds_out_buffer_is_half_full(struct wl_connection* c)
wl_connection *c
> +{
> + return wl_buffer_size(>fds_out) > MAX_FDS_OUT * sizeof(int32_t) /
> 2;
> +}
> +
> +static int
> +connection_soft_flush_check(struct wl_connection* connection)
connection_soft_flush_needed? Then true/false return value is more
obvious.
> +{
> + /* For a soft flush, We use the the data buffer being half full, or
> the
> +* fds_out buffer being at half the message limit as the criteria for
> +* actually performing a flush. */
> +
> + return wl_buffer_is_half_full(>out) ||
> + wl_fds_out_buffer_is_half_full(connection);
> +}
Block indent should be tabs, not spaces.
> +
> int
> -wl_connection_flush(struct wl_connection *connection)
> +wl_connection_flush(struct wl_connection *connection, int soft)
> {
> struct iovec iov[2];
> struct msghdr msg;
> @@ -297,6 +320,9 @@ wl_connection_flush(struct wl_connection *connection)
> if (!connection->want_flush)
> return 0;
>
> + if (soft && !connection_soft_flush_check(connection))
> + return 0;
> +
> tail = connection->out.tail;
> while (connection->out.head - connection->out.tail > 0) {
> wl_buffer_get_iov(>out, iov, );
> @@ -400,7 +426,7 @@ wl_connection_queue(struct wl_connection *connection,
> if (connection->out.head - connection->out.tail +
> count > ARRAY_LENGTH(connection->out.data)) {
> connection->want_flush = 1;
> - if (wl_connection_flush(connection) < 0)
> + if (wl_connection_flush(connection, 0) < 0)
> return -1;
> }
>
> diff --git a/src/wayland-client-core.h b/src/wayland-client-core.h
> index 03e781b..84b3b41 100644
> --- a/src/wayland-client-core.h
> +++ b/src/wayland-client-core.h
> @@ -234,6 +234,9 @@ wl_display_get_protocol_error(struct wl_display *display,
> int
> wl_display_flush(struct wl_display *display);
>
> +int
> +wl_display_soft_flush(struct wl_display *display);
> +
> int
> wl_display_roundtrip_queue(struct wl_display *display,
> struct wl_event_queue *queue);
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index 29ae1e0..eea634d 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -1957,6 +1957,31 @@ wl_display_get_protocol_error(struct wl_display
> *display,
> return ret;
>
Re: [PATCH 2/2] proto, server: Add internal server error message. (v2)
On Tue, 22 Jan 2019 15:42:17 +1300 Christopher James Halse Rogers wrote: > On 20 November 2018 8:02:50 pm NZDT, Christopher James Halse Rogers > wrote: > >Many languages such as C++ or Rust have an unwinding error-reporting > >mechanism. Code in these languages can (and must!) wrap request > >handling > >callbacks in unwind guards to avoid undefined behaviour. > > > >As a consequence such code will detect internal server errors, but have > >no way to communicate such failures to the client. > > > >This adds a WL_DISPLAY_ERROR_IMPLEMENTATION error to wl_display so that > >such code can notify (and disconnect) clients which hit internal bugs. > >While servers can currently abuse other wl_display errors for the same > >effect, adding an explicit error code allows clients to tell the > >difference between errors which are their fault and errors which are > >the > >server's fault. This is particularly interesting for automated bug > >reporting. > > > >v2: Rename error from "internal" to "implementation", in sympathy with > >X11's BadImplementation error. > >Add more justification in the commit message. > > > >Signed-off-by: Christopher James Halse Rogers > > > >Acked-by: Pekka Paalanen > >--- > > protocol/wayland.xml | 2 ++ > > src/wayland-client.c | 3 +++ > > src/wayland-server-core.h | 4 > > src/wayland-server.c | 24 +++ > > tests/display-test.c | 40 +++ > > 5 files changed, 73 insertions(+) > Ping! > > Is there anything I can do to make these patches more appealing? Hi raof, not for me, I just need the time to get there. :-) Thanks, pq pgp857lrq862I.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] Weston GL shader compilation re-design
Hi Pekka, Thank you for the comments. I wIll start implementing the shader building. Pekka Paalanen writes: > On Wed, 23 Jan 2019 11:32:34 +0530 > Harish Krupo wrote: > >> Hi, >> >> This is in continuation to the discussion in the mail chain here [1]. We >> are currently working on enabling HDR rendering support in the >> gl-renderer. HDR support requires color space conversion (709->2020 or >> other way around) and Tone Mapping, for which, we need to execute the >> following steps in the shader: >> * Degamma (to linearize the buffer) >> * Color space conversion (BT2020 -> BT709...) >> * Tone mapping (SDR -> HDR, HDR -> SDR, HDR -> HDR conversion) >> * Gamma: Apply gamma/transfer function for the display (PQ/HLG...) >> >> We are currently targeting the DCI-P3, SRGB and 2084 color spaces. One >> way to implement it would be to create multiple sets of shaders for each >> degamma/gamma combination. Like the one done by Ville in his POC [2]. >> This solution was a POC, and isn't scalable when we need to support >> multiple color spaces. I would like to propose 2 different solutions: >> >> Proposal 1: >> * Each of the shaders (gamma/degamma/main/tone mapping) would be >> independent strings. >> * When the view needs to be rendered, renderer will generate a set of >> requirements like need degamma PQ curve, need tone mapping, need gamma >> SRGB curve and so on. >> * These requirements (NEED_GAMMA_PQ...) would be bit fields and will be >> OR'd to create the total requirements. >> * This total requirement would be used to stitch the required shaders to >> compile a program. The total requirements integer will also be used as >> a key to store that program in a hashmap for re-use. >> >> Proposal 2: >> We could go for multi pass rendering, where each of the steps (gamma, >> csc, tone mappping, degamma) will be applied in different passes. Each >> pass would bind an fbo and call draw elements with the corresponding >> shader. This would not be as efficient but is another approach. >> >> Please comment on the approaches and do suggest if there is a better >> one. > > Hi Harish, > > choosing between multipass rendering and more complicated shader > building, I would definitely take the more complicated shader building > first. If the use case is video playback, then the clients will be > updating very often and the frames they produce will likely ever be > composited just once. Using multipass with intermediate buffers would > just blow up the memory bandwidth usage. > > Later, if someone wants to optimize things more for rarely updating > surfaces, they could implement an image cache for some stages of the > pixel conversions. > > Precision is another benefit of a complicated shader that does > everything in one go: the intermediate values in the shader can be > stored in GPU registers at high precision. Achieving the same precision > with multipass would cost a huge amount of memory. Memory saving is a > big reason why one almost always store images with gamma applied, even > in memory rather than just files. > > Btw. when enhancing the fragment shader mechanics, I think we could > rely more on the GLSL compilers than we do today. What I mean by that > is that we could have the shader's main call functions that do each of > the conversion steps to the pixel values, and then when concatenating > the shader string, we pick the appropriate function implementations into > it. No-op or pass-through functions ideally shouldn't produce any worse > code than manually not calling them. IOW, go with a more function than > macro oriented design in assembling the complete frament shader string. > > I think code maintainability and clarity should be the foremost goal, > but avoiding any serious performance issues. Fine-tuning the shader > performance, e.g. investigating a single "megashader" vs. multiple > specific shaders can be left out for now. Unless someone has solid > knowledge about what would be best already? > > Of course, we should stick to GL ES 2.0 capabilities if possible, but > we could also consider requiring GL ES 3.0 if that would seem too > useful to ignore. > > > Thanks, > pq > >> >> [1] >> https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html >> >> [2] >> https://github.com/vsyrjala/weston/blob/hdr_poc/libweston/gl-renderer.c#L257 Regards Harish Krupo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] Weston GL shader compilation re-design
On Wed, 23 Jan 2019 11:32:34 +0530 Harish Krupo wrote: > Hi, > > This is in continuation to the discussion in the mail chain here [1]. We > are currently working on enabling HDR rendering support in the > gl-renderer. HDR support requires color space conversion (709->2020 or > other way around) and Tone Mapping, for which, we need to execute the > following steps in the shader: > * Degamma (to linearize the buffer) > * Color space conversion (BT2020 -> BT709...) > * Tone mapping (SDR -> HDR, HDR -> SDR, HDR -> HDR conversion) > * Gamma: Apply gamma/transfer function for the display (PQ/HLG...) > > We are currently targeting the DCI-P3, SRGB and 2084 color spaces. One > way to implement it would be to create multiple sets of shaders for each > degamma/gamma combination. Like the one done by Ville in his POC [2]. > This solution was a POC, and isn't scalable when we need to support > multiple color spaces. I would like to propose 2 different solutions: > > Proposal 1: > * Each of the shaders (gamma/degamma/main/tone mapping) would be > independent strings. > * When the view needs to be rendered, renderer will generate a set of > requirements like need degamma PQ curve, need tone mapping, need gamma > SRGB curve and so on. > * These requirements (NEED_GAMMA_PQ...) would be bit fields and will be > OR'd to create the total requirements. > * This total requirement would be used to stitch the required shaders to > compile a program. The total requirements integer will also be used as > a key to store that program in a hashmap for re-use. > > Proposal 2: > We could go for multi pass rendering, where each of the steps (gamma, > csc, tone mappping, degamma) will be applied in different passes. Each > pass would bind an fbo and call draw elements with the corresponding > shader. This would not be as efficient but is another approach. > > Please comment on the approaches and do suggest if there is a better > one. Hi Harish, choosing between multipass rendering and more complicated shader building, I would definitely take the more complicated shader building first. If the use case is video playback, then the clients will be updating very often and the frames they produce will likely ever be composited just once. Using multipass with intermediate buffers would just blow up the memory bandwidth usage. Later, if someone wants to optimize things more for rarely updating surfaces, they could implement an image cache for some stages of the pixel conversions. Precision is another benefit of a complicated shader that does everything in one go: the intermediate values in the shader can be stored in GPU registers at high precision. Achieving the same precision with multipass would cost a huge amount of memory. Memory saving is a big reason why one almost always store images with gamma applied, even in memory rather than just files. Btw. when enhancing the fragment shader mechanics, I think we could rely more on the GLSL compilers than we do today. What I mean by that is that we could have the shader's main call functions that do each of the conversion steps to the pixel values, and then when concatenating the shader string, we pick the appropriate function implementations into it. No-op or pass-through functions ideally shouldn't produce any worse code than manually not calling them. IOW, go with a more function than macro oriented design in assembling the complete frament shader string. I think code maintainability and clarity should be the foremost goal, but avoiding any serious performance issues. Fine-tuning the shader performance, e.g. investigating a single "megashader" vs. multiple specific shaders can be left out for now. Unless someone has solid knowledge about what would be best already? Of course, we should stick to GL ES 2.0 capabilities if possible, but we could also consider requiring GL ES 3.0 if that would seem too useful to ignore. Thanks, pq > > [1] > https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html > [2] > https://github.com/vsyrjala/weston/blob/hdr_poc/libweston/gl-renderer.c#L257 pgpEGpL1fPnio.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Fbdev-backend removal from Weston (Re: Upcoming release)
On Tue, 22 Jan 2019 22:46:02 -0500 nerdopolis wrote: > On Tuesday, January 22, 2019 9:55:15 AM EST Pekka Paalanen wrote: > > > > On Tue, 22 Jan 2019 10:17:32 +0200 > > Pekka Paalanen wrote: > > > > > Hi, > > > > > > do you actually have a use case for that? It's ok if you do, we can > > > keep it around for some more, but the simple fact that some hardware > > > exists that does not have a working DRM driver is not enough. There > > > should be users too. > > > > > > The fbdev-backend certainly has its shortcomings, and I don't mean just > > > the lack of multi-output or monitor hotplug or GPU acceleration or > > > tearing or timings based on nothing but timers; I recall VT-switching > > > being broken for years now, and it doesn't (cannot?) use logind to open > > > the FB devices. Did I forget some? > > Hi > > Well, TBH, It's just my quazi-distribution Live CD that I still maintain... > It falls back to the Framebuffer on systems (or seats) that don't have > Kernel Mode Setting. The number of users now probably is low... Right. Would you be able to do a test? Disable fbdev on your distro and see if anyone complains? In fact, would be nice if all distributions did that test. I'm not in that much hurry to delete the backend yet. > VT switching works great. It works without weston-launch, and I can switch > away > to a second instance of Weston using the Framebuffer, without them stepping on > each other, and I can switch back to the original one, and it continues > working > > I do have to create a udev file that sets > SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess" > though... Yes, that rule or similar is required because logind does not deal fb devices IIRC and Weston certainly doesn't ask. Are you relying on logind or running Weston privileged to have VT switching working? It's been a long time since I tried VT-switching with fbdev, but it didn't work with logind back then: https://gitlab.freedesktop.org/wayland/weston/issues/78 Could it have been fixed in logind instead? Thanks, pq pgpofY2eJYo8X.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
