All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "Christian König" <christian.koenig@amd.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Rob Clark" <robdclark@chromium.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Jack Zhang" <Jack.Zhang1@amd.com>,
	"Gustavo Padovan" <gustavo@padovan.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	"Luben Tuikov" <luben.tuikov@amd.com>,
	"Roy Sun" <Roy.Sun@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Tian Tao" <tiantao6@hisilicon.com>,
	"Lee Jones" <lee.jones@linaro.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [RFC 0/4] dma-fence: Deadline awareness
Date: Thu, 29 Jul 2021 14:00:24 +0300	[thread overview]
Message-ID: <20210729140024.6a635be4@eldfell> (raw)
In-Reply-To: <15cf73a8-eda4-3559-561a-a05a14f445d0@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

On Thu, 29 Jul 2021 12:14:18 +0200
Christian König <ckoenig.leichtzumerken@gmail.com> wrote:

> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
> >
> > If the app happens to be frozen (e.g. some weird bug in fence handling
> > to make it never ready, or maybe it's just bugged itself and never
> > drawing again), then the app is frozen, and all the rest of the desktop
> > continues running normally without a glitch.  
> 
> But that is in contradict to what you told me before.
> 
> See when the window should move but fails to draw it's new content what 
> happens?
> 
> Are the other windows which would be affected by the move not drawn as well?

No, all the other windows will continue behaving normally just like
they always did. It's just that one frozen window there that won't
update; it won't resize, so there is no reason to move that other
window either.

Everything continues as if the frozen window never even sent anything
to the compositor after its last good update.

We have a principle in Wayland: the compositor cannot afford to wait
for clients, the desktop as a whole must remain responsive. So there is
always a backup plan even for cases where the compositor expects the
client to change something. For resizes, in a floating-window manager
it's easy: just let things continue as they are; in a tiling window
manager they may have a timeout after which... whatever is appropriate.

Another example: If a compositor decides to make a window maximized, it
tells the client the new size and state it must have. Until the client
acks that specific state change, the compositor will continue managing
that window as if nothing changed. Given the asynchronous nature of
Wayland, the client might even continue submitting updates
non-maximized for a while, and that will go through as if the
compositor didn't ask for maximized. But at some point the client acks
the window state change, and from that point on if it doesn't behave
like maximized state requires, it will get a protocol error and be
disconnected.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "Rob Clark" <robdclark@chromium.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Jack Zhang" <Jack.Zhang1@amd.com>,
	"Gustavo Padovan" <gustavo@padovan.org>,
	"Michel Dänzer" <michel@daenzer.net>,
	"open list" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	"Luben Tuikov" <luben.tuikov@amd.com>,
	"Roy Sun" <Roy.Sun@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Tian Tao" <tiantao6@hisilicon.com>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [RFC 0/4] dma-fence: Deadline awareness
Date: Thu, 29 Jul 2021 14:00:24 +0300	[thread overview]
Message-ID: <20210729140024.6a635be4@eldfell> (raw)
In-Reply-To: <15cf73a8-eda4-3559-561a-a05a14f445d0@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

On Thu, 29 Jul 2021 12:14:18 +0200
Christian König <ckoenig.leichtzumerken@gmail.com> wrote:

> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
> >
> > If the app happens to be frozen (e.g. some weird bug in fence handling
> > to make it never ready, or maybe it's just bugged itself and never
> > drawing again), then the app is frozen, and all the rest of the desktop
> > continues running normally without a glitch.  
> 
> But that is in contradict to what you told me before.
> 
> See when the window should move but fails to draw it's new content what 
> happens?
> 
> Are the other windows which would be affected by the move not drawn as well?

No, all the other windows will continue behaving normally just like
they always did. It's just that one frozen window there that won't
update; it won't resize, so there is no reason to move that other
window either.

Everything continues as if the frozen window never even sent anything
to the compositor after its last good update.

We have a principle in Wayland: the compositor cannot afford to wait
for clients, the desktop as a whole must remain responsive. So there is
always a backup plan even for cases where the compositor expects the
client to change something. For resizes, in a floating-window manager
it's easy: just let things continue as they are; in a tiling window
manager they may have a timeout after which... whatever is appropriate.

Another example: If a compositor decides to make a window maximized, it
tells the client the new size and state it must have. Until the client
acks that specific state change, the compositor will continue managing
that window as if nothing changed. Given the asynchronous nature of
Wayland, the client might even continue submitting updates
non-maximized for a while, and that will go through as if the
compositor didn't ask for maximized. But at some point the client acks
the window state change, and from that point on if it doesn't behave
like maximized state requires, it will get a protocol error and be
disconnected.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-07-29 11:00 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 23:38 [RFC 0/4] dma-fence: Deadline awareness Rob Clark
2021-07-26 23:38 ` Rob Clark
2021-07-26 23:38 ` [RFC 1/4] dma-fence: Add deadline awareness Rob Clark
2021-07-26 23:38   ` Rob Clark
2021-07-27  7:11   ` Christian König
2021-07-27  7:11     ` Christian König
2021-07-27 14:25     ` Rob Clark
2021-07-27 14:25       ` Rob Clark
2021-07-28  7:03       ` Christian König
2021-07-28  7:03         ` Christian König
2021-07-28 11:37         ` Christian König
2021-07-28 11:37           ` Christian König
2021-07-28 15:15           ` Rob Clark
2021-07-28 15:15             ` Rob Clark
2021-07-28 17:23             ` Christian König
2021-07-28 17:23               ` Christian König
2021-07-28 17:58               ` Rob Clark
2021-07-28 17:58                 ` Rob Clark
2021-07-29  7:03                 ` Daniel Vetter
2021-07-29  7:03                   ` Daniel Vetter
2021-07-29 15:23                   ` Rob Clark
2021-07-29 15:23                     ` Rob Clark
2021-07-29 16:18                     ` Daniel Vetter
2021-07-29 16:18                       ` Daniel Vetter
2021-07-29 17:32                       ` Rob Clark
2021-07-29 17:32                         ` Rob Clark
2021-07-26 23:38 ` [RFC 2/4] drm/vblank: Add helper to get next vblank time Rob Clark
2021-07-26 23:38   ` Rob Clark
2021-07-26 23:38 ` [RFC 3/4] drm/atomic-helper: Set fence deadline for vblank Rob Clark
2021-07-26 23:38   ` Rob Clark
2021-07-27 10:44   ` Michel Dänzer
2021-07-27 10:44     ` Michel Dänzer
2021-07-27 14:33     ` Rob Clark
2021-07-27 14:33       ` Rob Clark
2021-07-26 23:38 ` [RFC 4/4] drm/scheduler: Add fence deadline support Rob Clark
2021-07-26 23:38   ` Rob Clark
2021-07-26 23:51 ` [RFC 0/4] dma-fence: Deadline awareness Rob Clark
2021-07-26 23:51   ` Rob Clark
2021-07-27 14:41 ` Michel Dänzer
2021-07-27 14:41   ` Michel Dänzer
2021-07-27 15:12   ` Rob Clark
2021-07-27 15:12     ` Rob Clark
2021-07-27 15:19     ` Michel Dänzer
2021-07-27 15:37       ` Rob Clark
2021-07-27 15:37         ` Rob Clark
2021-07-28 11:36         ` Christian König
2021-07-28 11:36           ` Christian König
2021-07-28 13:08           ` Michel Dänzer
2021-07-28 13:13             ` Christian König
2021-07-28 13:13               ` Christian König
2021-07-28 13:24               ` Michel Dänzer
2021-07-28 13:24                 ` Michel Dänzer
2021-07-28 13:31                 ` Christian König
2021-07-28 13:31                   ` Christian König
2021-07-28 13:57                   ` Pekka Paalanen
2021-07-28 13:57                     ` Pekka Paalanen
2021-07-28 14:30                     ` Christian König
2021-07-28 14:30                       ` Christian König
2021-07-29  8:08                       ` Michel Dänzer
2021-07-29  8:23                       ` Pekka Paalanen
2021-07-29  8:23                         ` Pekka Paalanen
2021-07-29  8:43                         ` Christian König
2021-07-29  8:43                           ` Christian König
2021-07-29  9:15                           ` Pekka Paalanen
2021-07-29  9:15                             ` Pekka Paalanen
2021-07-29 10:14                             ` Christian König
2021-07-29 10:14                               ` Christian König
2021-07-29 10:28                               ` Michel Dänzer
2021-07-29 10:28                                 ` Michel Dänzer
2021-07-29 11:00                               ` Pekka Paalanen [this message]
2021-07-29 11:00                                 ` Pekka Paalanen
2021-07-29 11:43                                 ` Christian König
2021-07-29 11:43                                   ` Christian König
2021-07-29 12:49                                   ` Pekka Paalanen
2021-07-29 12:49                                     ` Pekka Paalanen
2021-07-29 13:41                                     ` Christian König
2021-07-29 13:41                                       ` Christian König
2021-07-29 14:10                                       ` Pekka Paalanen
2021-07-29 14:10                                         ` Pekka Paalanen
2021-07-28 15:27                     ` Rob Clark
2021-07-28 15:27                       ` Rob Clark
2021-07-28 17:20                       ` Christian König
2021-07-28 15:34                 ` Rob Clark
2021-07-28 15:34                   ` Rob Clark
2021-07-29  7:09                   ` Daniel Vetter
2021-07-29  7:09                     ` Daniel Vetter
2021-07-29  8:17                     ` Michel Dänzer
2021-07-29  8:17                       ` Michel Dänzer
2021-07-29  9:03                       ` Daniel Vetter
2021-07-29  9:03                         ` Daniel Vetter
2021-07-29  9:37                         ` Pekka Paalanen
2021-07-29  9:37                           ` Pekka Paalanen
2021-07-29 12:18                           ` Daniel Vetter
2021-07-29 12:18                             ` Daniel Vetter
2021-07-29 12:59                             ` Pekka Paalanen
2021-07-29 12:59                               ` Pekka Paalanen
2021-07-29 14:05                               ` Daniel Vetter
2021-07-29 14:05                                 ` Daniel Vetter
2021-07-27 21:17 ` [RFC 5/4] drm/msm: Add deadline based boost support Rob Clark
2021-07-27 21:17   ` Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210729140024.6a635be4@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=Jack.Zhang1@amd.com \
    --cc=Roy.Sun@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=lee.jones@linaro.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=luben.tuikov@amd.com \
    --cc=matthew.brost@intel.com \
    --cc=michel@daenzer.net \
    --cc=robdclark@chromium.org \
    --cc=tiantao6@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.