From: Daniel Vetter <daniel@ffwll.ch>
To: "Kristian Høgsberg" <hoegsberg@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC PATCH] drm: Add plane event
Date: Thu, 19 Apr 2012 10:05:57 +0200 [thread overview]
Message-ID: <20120419080557.GC4256@phenom.ffwll.local> (raw)
In-Reply-To: <CAOeoa-exhQHDKWH0DpODNFEcUUhZp4HfYY-ZZk33h+nbbVBTpQ@mail.gmail.com>
On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian Høgsberg wrote:
> One thing that's not clear to me is how we would enable a sprite
> without going through the atomic modeset again. If the atomic modeset
> is all about calculating bandwidth requirements etc, then enabling a
> sprite will affect that and it may or may not be possible based on the
> current configuration. However, enabling a sprite from one frame to
> another is something that we would want to do as part of the nuclear
> pageflip. So I'm not sure how this would work... maybe we could have
> a prepare_sprite_enable type ioctl that verifies that it's possible to
> add the sprite plane to the current configuration. Then if that
> succeeds, we can use the nuclear pageflip to enable the sprite plane.
Sprites also have an ugly issue wrt finer-grained locking: If we move to
per-crtc locking, the nuclear pageflip would only need to take the crtc
mutex it operates on. But the if we move a sprite from one crtc to another
one, we'd need to lock both crtcs, and the easiest solution for the lock
ordering problem this causes is to require that all code which needs more
than one crtc look needs the big modeset lock. Which would be painful for
pageflip.
Also, most sprites/overlays can't be switched in one step from one crtc to
another, so these pageflips would run synchronous. Which is not the point of
pageflipping. So I think a prepare_sprite ioctl which changes the crtc
association (and checks memory bandwidth and other constrains) but does
not display anything would be good to support the nuclear pageflip without
jumping through too many hoops in the kernel. Nuclear pageflip would need
to support pageflippping from/to NULL framebuffers on planes then to
signal switching a plane on/off. Maybe we could even do that for the main
crtc fb (and add a background color), e.g. for video watch to avoid
scanning out black bars.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-04-19 8:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 4:31 [RFC PATCH] drm: Add plane event Joonyoung Shim
2012-04-18 8:46 ` Daniel Vetter
2012-04-18 10:11 ` Joonyoung Shim
2012-04-18 12:25 ` Rob Clark
2012-04-18 14:04 ` Marcus Lorentzon
2012-04-18 14:26 ` Ville Syrjälä
2012-04-18 14:36 ` Daniel Vetter
2012-04-18 15:10 ` Marcus Lorentzon
2012-04-18 15:27 ` Daniel Vetter
2012-04-18 15:55 ` Marcus Lorentzon
2012-04-18 16:04 ` Jesse Barnes
2012-04-18 19:08 ` Daniel Vetter
2012-04-18 16:06 ` Ville Syrjälä
2012-04-18 16:26 ` Marcus Lorentzon
2012-04-18 18:19 ` Ville Syrjälä
2012-04-19 8:10 ` Daniel Vetter
2012-04-18 15:43 ` Luc Verhaegen
2012-04-18 16:00 ` Marcus Lorentzon
2012-04-19 1:24 ` Kristian Høgsberg
2012-04-19 8:05 ` Daniel Vetter [this message]
2012-04-18 14:58 ` Marcus Lorentzon
2012-04-18 15:57 ` Jesse Barnes
2012-04-18 16:47 ` Luc Verhaegen
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=20120419080557.GC4256@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@gmail.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.