u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To: u-boot@lists.denx.de
Cc: Kever Yang <kever.yang@rock-chips.com>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Svyatoslav Ryhel <clamor95@gmail.com>,
	Alexander Graf <agraf@csgraf.de>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Andrew Davis <afd@ti.com>, Da Xue <da@libre.computer>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Patrice Chotard <patrice.chotard@foss.st.com>,
	Patrick Delaunay <patrick.delaunay@foss.st.com>,
	Derald Woods <woods.technical@gmail.com>,
	Anatolij Gustschin <agust@denx.de>,
	uboot-stm32@st-md-mailman.stormreply.com,
	Simon Glass <sjg@chromium.org>,
	Matthias Brugger <mbrugger@suse.com>,
	u-boot-amlogic@groups.io,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Alper Nebi Yasak <alpernebiyasak@gmail.com>
Subject: [PATCH v5 00/13] Add video damage tracking
Date: Mon, 21 Aug 2023 16:50:57 +0300	[thread overview]
Message-ID: <20230821135111.3558478-1-alpernebiyasak@gmail.com> (raw)

This is a rebase of Alexander Graf's video damage tracking series, with
some tests and other changes. The original cover letter is as follows:

> This patch set speeds up graphics output on ARM by a factor of 60x.
>
> On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached,
> but need it accessible by the display controller which reads directly
> from a later point of consistency. Hence, we flush the frame buffer to
> DRAM on every change. The full frame buffer.
>
> Unfortunately, with the advent of 4k displays, we are seeing frame buffers
> that can take a while to flush out. This was reported by Da Xue with grub,
> which happily print 1000s of spaces on the screen to draw a menu. Every
> printed space triggers a cache flush.
>
> This patch set implements the easiest mitigation against this problem:
> Damage tracking. We remember the lowest common denominator region that was
> touched since the last video_sync() call and only flush that. The most
> typical writer to the frame buffer is the video console, which always
> writes rectangles of characters on the screen and syncs afterwards.
>
> With this patch set applied, we reduce drawing a large grub menu (with
> serial console attached for size information) on an RK3399-ROC system
> at 1440p from 55 seconds to less than 1 second.
>
> Version 2 also implements VIDEO_COPY using this mechanism, reducing its
> overhead compared to before as well. So even x86 systems should be faster
> with this now :).
>
>
> Alternatives considered:
>
>   1) Lazy sync - Sandbox does this. It only calls video_sync(true) ever
>      so often. We are missing timers to do this generically.
>
>   2) Double buffering - We could try to identify whether anything changed
>      at all and only draw to the FB if it did. That would require
>      maintaining a second buffer that we need to scan.
>
>   3) Text buffer - Maintain a buffer of all text printed on the screen with
>      respective location. Don't write if the old and new character are
>      identical. This would limit applicability to text only and is an
>      optimization on top of this patch set.
>
>   4) Hash screen lines - Create a hash (sha256?) over every line when it
>      changes. Only flush when it does. I'm not sure if this would waste
>      more time, memory and cache than the current approach. It would make
>      full screen updates much more expensive.

Changes in v5:
- Add patch "video: test: Split copy frame buffer check into a function"
- Add patch "video: test: Support checking copy frame buffer contents"
- Add patch "video: test: Test partial updates of hardware frame buffer"
- Use xstart, ystart, xend, yend as names for damage region
- Document damage struct and fields in struct video_priv comment
- Return void from video_damage()
- Fix undeclared priv error in video_sync()
- Drop unused headers from video-uclass.c
- Use IS_ENABLED() instead of CONFIG_IS_ENABLED()
- Call video_damage() also in video_fill_part()
- Use met->baseline instead of priv->baseline
- Use fontdata->height/width instead of VIDEO_FONT_HEIGHT/WIDTH
- Update console_rotate.c video_damage() calls to pass video tests
- Remove mention about not having minimal damage for console_rotate.c
- Add patch "video: test: Test video damage tracking via vidconsole"
- Document new vdev field in struct efi_gop_obj comment
- Remove video_sync_copy() also from video_fill(), video_fill_part()
- Fix memmove() calls by removing the extra dev argument
- Call video_sync() before checking copy_fb in video tests
- Imply VIDEO_DAMAGE for video drivers instead of selecting it
- Imply VIDEO_DAMAGE also for VIDEO_TIDSS

v4: https://lore.kernel.org/all/20230103215004.22646-1-agraf@csgraf.de/

Changes in v4:
- Move damage clear to patch "dm: video: Add damage tracking API"
- Simplify first damage logic
- Remove VIDEO_DAMAGE default for ARM
- Skip damage on EfiBltVideoToBltBuffer
- Add patch "video: Always compile cache flushing code"
- Add patch "video: Enable VIDEO_DAMAGE for drivers that need it"

v3: https://lore.kernel.org/all/20221230195828.88134-1-agraf@csgraf.de/

Changes in v3:
- Adapt to always assume DM is used
- Adapt to always assume DM is used
- Make VIDEO_COPY always select VIDEO_DAMAGE

v2: https://lore.kernel.org/all/20220609225921.62462-1-agraf@csgraf.de/

Changes in v2:
- Remove ifdefs
- Fix ranges in truetype target
- Limit rotate to necessary damage
- Remove ifdefs from gop
- Fix dcache range; we were flushing too much before
- Add patch "video: Use VIDEO_DAMAGE for VIDEO_COPY"

v1: https://lore.kernel.org/all/20220606234336.5021-1-agraf@csgraf.de/

Alexander Graf (9):
  dm: video: Add damage tracking API
  dm: video: Add damage notification on display fills
  vidconsole: Add damage notifications to all vidconsole drivers
  video: Add damage notification on bmp display
  efi_loader: GOP: Add damage notification on BLT
  video: Only dcache flush damaged lines
  video: Use VIDEO_DAMAGE for VIDEO_COPY
  video: Always compile cache flushing code
  video: Enable VIDEO_DAMAGE for drivers that need it

Alper Nebi Yasak (4):
  video: test: Split copy frame buffer check into a function
  video: test: Support checking copy frame buffer contents
  video: test: Test partial updates of hardware frame buffer
  video: test: Test video damage tracking via vidconsole

 arch/arm/mach-omap2/omap3/Kconfig |   1 +
 arch/arm/mach-sunxi/Kconfig       |   1 +
 drivers/video/Kconfig             |  26 +++
 drivers/video/console_normal.c    |  27 ++--
 drivers/video/console_rotate.c    |  94 +++++++----
 drivers/video/console_truetype.c  |  37 +++--
 drivers/video/exynos/Kconfig      |   1 +
 drivers/video/imx/Kconfig         |   1 +
 drivers/video/meson/Kconfig       |   1 +
 drivers/video/rockchip/Kconfig    |   1 +
 drivers/video/stm32/Kconfig       |   1 +
 drivers/video/tegra20/Kconfig     |   1 +
 drivers/video/tidss/Kconfig       |   1 +
 drivers/video/vidconsole-uclass.c |  16 --
 drivers/video/video-uclass.c      | 190 ++++++++++++----------
 drivers/video/video_bmp.c         |   7 +-
 include/video.h                   |  59 +++----
 include/video_console.h           |  52 ------
 lib/efi_loader/efi_gop.c          |   7 +
 test/dm/video.c                   | 256 ++++++++++++++++++++++++------
 20 files changed, 483 insertions(+), 297 deletions(-)


base-commit: 3881c9fbb7fdd98f6eae5cd33f7e9abe9455a585
-- 
2.40.1


             reply	other threads:[~2023-08-21 13:51 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-21 13:50 Alper Nebi Yasak [this message]
2023-08-21 13:50 ` [PATCH v5 01/13] video: test: Split copy frame buffer check into a function Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:50 ` [PATCH v5 02/13] video: test: Support checking copy frame buffer contents Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 03/13] video: test: Test partial updates of hardware frame buffer Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 04/13] dm: video: Add damage tracking API Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-30 19:15     ` Alper Nebi Yasak
2023-08-31  2:49       ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 05/13] dm: video: Add damage notification on display fills Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 06/13] vidconsole: Add damage notifications to all vidconsole drivers Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 07/13] video: test: Test video damage tracking via vidconsole Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 08/13] video: Add damage notification on bmp display Alper Nebi Yasak
2023-08-21 13:51 ` [PATCH v5 09/13] efi_loader: GOP: Add damage notification on BLT Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 10/13] video: Only dcache flush damaged lines Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 19:59     ` Alexander Graf
2023-08-21 22:10       ` Simon Glass
2023-08-21 22:44         ` Alexander Graf
2023-08-21 23:03           ` Simon Glass
2023-08-30 19:12             ` Alper Nebi Yasak
2023-08-30 19:57               ` Alexander Graf
2023-08-21 13:51 ` [PATCH v5 11/13] video: Use VIDEO_DAMAGE for VIDEO_COPY Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 20:06     ` Alexander Graf
2023-08-30 19:07       ` Alper Nebi Yasak
2023-08-31  2:49         ` Simon Glass
2023-08-21 13:51 ` [PATCH v5 12/13] video: Always compile cache flushing code Alper Nebi Yasak
2023-08-21 13:51 ` [PATCH v5 13/13] video: Enable VIDEO_DAMAGE for drivers that need it Alper Nebi Yasak
2023-08-21 19:11   ` Simon Glass
2023-08-21 19:11 ` [PATCH v5 00/13] Add video damage tracking Simon Glass
2023-08-21 19:33   ` Alexander Graf
2023-08-21 19:57     ` Simon Glass
2023-08-21 20:20       ` Alexander Graf
2023-08-21 22:10         ` Simon Glass
2023-08-21 22:40           ` Alexander Graf
2023-08-21 23:03             ` Simon Glass
2023-08-22  7:47               ` Alexander Graf
2023-08-22 18:56                 ` Simon Glass
2023-08-23  8:56                   ` Alexander Graf
2023-08-28 17:54                     ` Simon Glass
2023-08-28 20:24                       ` Alexander Graf
2023-08-28 21:54                         ` Heinrich Schuchardt
2023-08-29  6:20                           ` Alexander Graf
2023-08-29  9:19                             ` Mark Kettenis
2023-08-30 19:55                               ` Alexander Graf
2023-08-28 22:08                         ` Simon Glass
2023-08-29  6:27                           ` Alexander Graf
2023-08-30 18:27                             ` Alper Nebi Yasak
2023-08-30 19:52                               ` Alexander Graf

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=20230821135111.3558478-1-alpernebiyasak@gmail.com \
    --to=alpernebiyasak@gmail.com \
    --cc=afd@ti.com \
    --cc=agraf@csgraf.de \
    --cc=agust@denx.de \
    --cc=andre.przywara@arm.com \
    --cc=clamor95@gmail.com \
    --cc=da@libre.computer \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jagan@amarulasolutions.com \
    --cc=kever.yang@rock-chips.com \
    --cc=mbrugger@suse.com \
    --cc=neil.armstrong@linaro.org \
    --cc=patrice.chotard@foss.st.com \
    --cc=patrick.delaunay@foss.st.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=sjg@chromium.org \
    --cc=u-boot-amlogic@groups.io \
    --cc=u-boot@lists.denx.de \
    --cc=uboot-stm32@st-md-mailman.stormreply.com \
    --cc=woods.technical@gmail.com \
    --cc=xypron.glpk@gmx.de \
    /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;
as well as URLs for NNTP newsgroup(s).