From: Thomas Hellstrom <thellstrom@vmware.com>
To: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: RFC: page-flip with damage?
Date: Sun, 24 Sep 2017 19:41:45 +0200 [thread overview]
Message-ID: <52d7547e-8d32-6b0b-e35f-392858415bbe@vmware.com> (raw)
Hi, list!
Page flips, while efficient on real hardware, aren't that efficient in
other situations, like for virtual devices with local, or even worse,
remote desktops.
We might ending up forwarding or encoding a couple of full frames worth
of data instead of a small region at a cursor blink.
Now there is this extension EGL_KHR_swap_buffers_with_damage, and
gnome-shell/wayland on KMS also has a damage region that it forwards all
the way down to the function where page-flip is called.
So I'd like to start looking at page-flips with damage, meaning that the
damage is an optional hint to the device about what part of the contents
is actually updated. What would be the best way to implement this? I
figure this can be done within the atomic context with a region attached
to the plane state? Would we want to follow the EGL extension and
forward an array of rects or for simplicity use a single bounding box?
Both these options would be a great win.
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2017-09-24 20:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-24 17:41 Thomas Hellstrom [this message]
2017-09-24 21:32 ` RFC: page-flip with damage? Rob Clark
2017-09-25 13:18 ` Noralf Trønnes
2017-09-26 7:01 ` Michal Lukaszek
2017-10-12 17:25 ` Deepak Singh Rawat
2017-09-26 8:18 ` RFC: " Daniel Vetter
2017-09-26 16:07 ` Thomas Hellstrom
2017-10-12 10:55 ` Pekka Paalanen
2017-10-12 14:51 ` Sean Paul
2017-10-13 6:41 ` Pekka Paalanen
2017-11-27 8:03 ` Thomas Hellstrom
2017-11-27 8:25 ` Daniel Vetter
2017-11-27 9:59 ` Thomas Hellstrom
2017-11-27 10:08 ` Daniel Vetter
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=52d7547e-8d32-6b0b-e35f-392858415bbe@vmware.com \
--to=thellstrom@vmware.com \
--cc=dri-devel@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox