From: Matthijs van Duin <matthijsvanduin@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "H . Nikolaus Schaller" <hns@goldelico.com>,
Merlijn Wajer <merlijn@wizzup.org>,
Sebastian Reichel <sre@kernel.org>,
dri-devel@lists.freedesktop.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-omap@vger.kernel.org
Subject: Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
Date: Sat, 4 Jan 2020 05:52:11 +0100 [thread overview]
Message-ID: <20200104045211.GA10025@chinchilla> (raw)
In-Reply-To: <20191221005711.47314-1-tony@atomide.com>
On Fri, Dec 20, 2019 at 04:57:11PM -0800, Tony Lindgren wrote:
> On my droid4 I noticed bad constant tearing on the LCD with stellarium in
> landscape mode with xorg-video-omap rotated with xrandr --rotate right.
> Every second or so update gets squeezed down in size to only the top half
> of the LCD panel.
Odd, there's not really a good reason for rotation to have any effect on
whether tearing happens or not.
BTW, with "top half", I assume you mean the top of the screen (i.e.
right side of the display), not the top of the display (i.e. left side
of the screen) ?
> This issue does not happen with xrandr --rotate normal, or when HDMI
> display is also connected.
Ehhhh, mirroring onto HDMI fixes the problem? Strange
> Looking around what might affect BO_TILED, I noticed Matthijs had this
> change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm:
> force tiled buffers to be pinned and page-aligned" has no commit log
> though, so I'm not sure what other issues this might fix.
This is just part of a hacky patch series to improve performance for
userspace access to tiled buffers. Page alignment has no effect by
itself, but it's necessary to allow the tiled memory allocated by
tiled_reserve_2d() to be mapped directly into userspace instead of using
the really slow "usergart" mechanism.
You can find the full patch series in github.com/mvduin/linux branch
4.15/patch/tiler-fast (based on mainline 4.15-rc6):
ae664249050b ARM: introduce pgprot_device()
fc1e8ffd1334 drm: omapdrm: improve choice of memory type for tiled memory
these improve performance on omap5/dra7 by mapping tiled buffers as
"device" memory by default instead of the pointlessly slow "strongly
ordered" which is currently used as a workaround for the
incompatibility between TILER and the bizarre way the ARM Cortex-A15
implements loads from normal non-cacheable memory.
3d4c98cc47dd XXX omapdrm: factor out _omap_gem_(un)pin
70593563f531 XXX omapdrm: force tiled buffers to be pinned and page-aligned
e061e454afd5 XXX omapdrm: fast userspace mapping of tiled buffers
these greatly improve performance of userspace access to tiled
buffers (on all devices that use tiler) at the expense of using more
tiler virtual memory. note that tiler virtual memory is a less
scarce resource on omap5/dra7 where 2d and 1d mappings have separate
page tables than on omap4 where they share a page table.
None of this should have any impact on tearing.
Matthijs
WARNING: multiple messages have this Message-ID (diff)
From: Matthijs van Duin <matthijsvanduin@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "H . Nikolaus Schaller" <hns@goldelico.com>,
Merlijn Wajer <merlijn@wizzup.org>,
Sebastian Reichel <sre@kernel.org>,
dri-devel@lists.freedesktop.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-omap@vger.kernel.org
Subject: Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED
Date: Sat, 4 Jan 2020 05:52:11 +0100 [thread overview]
Message-ID: <20200104045211.GA10025@chinchilla> (raw)
In-Reply-To: <20191221005711.47314-1-tony@atomide.com>
On Fri, Dec 20, 2019 at 04:57:11PM -0800, Tony Lindgren wrote:
> On my droid4 I noticed bad constant tearing on the LCD with stellarium in
> landscape mode with xorg-video-omap rotated with xrandr --rotate right.
> Every second or so update gets squeezed down in size to only the top half
> of the LCD panel.
Odd, there's not really a good reason for rotation to have any effect on
whether tearing happens or not.
BTW, with "top half", I assume you mean the top of the screen (i.e.
right side of the display), not the top of the display (i.e. left side
of the screen) ?
> This issue does not happen with xrandr --rotate normal, or when HDMI
> display is also connected.
Ehhhh, mirroring onto HDMI fixes the problem? Strange
> Looking around what might affect BO_TILED, I noticed Matthijs had this
> change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm:
> force tiled buffers to be pinned and page-aligned" has no commit log
> though, so I'm not sure what other issues this might fix.
This is just part of a hacky patch series to improve performance for
userspace access to tiled buffers. Page alignment has no effect by
itself, but it's necessary to allow the tiled memory allocated by
tiled_reserve_2d() to be mapped directly into userspace instead of using
the really slow "usergart" mechanism.
You can find the full patch series in github.com/mvduin/linux branch
4.15/patch/tiler-fast (based on mainline 4.15-rc6):
ae664249050b ARM: introduce pgprot_device()
fc1e8ffd1334 drm: omapdrm: improve choice of memory type for tiled memory
these improve performance on omap5/dra7 by mapping tiled buffers as
"device" memory by default instead of the pointlessly slow "strongly
ordered" which is currently used as a workaround for the
incompatibility between TILER and the bizarre way the ARM Cortex-A15
implements loads from normal non-cacheable memory.
3d4c98cc47dd XXX omapdrm: factor out _omap_gem_(un)pin
70593563f531 XXX omapdrm: force tiled buffers to be pinned and page-aligned
e061e454afd5 XXX omapdrm: fast userspace mapping of tiled buffers
these greatly improve performance of userspace access to tiled
buffers (on all devices that use tiler) at the expense of using more
tiler virtual memory. note that tiler virtual memory is a less
scarce resource on omap5/dra7 where 2d and 1d mappings have separate
page tables than on omap4 where they share a page table.
None of this should have any impact on tearing.
Matthijs
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-04 4:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-21 0:57 [PATCH] drm/omap: gem: Fix tearing with BO_TILED Tony Lindgren
2019-12-21 0:57 ` Tony Lindgren
2019-12-21 16:41 ` Tony Lindgren
2019-12-21 16:41 ` Tony Lindgren
2020-01-04 5:09 ` Matthijs van Duin
2020-01-04 5:09 ` Matthijs van Duin
2020-01-04 5:50 ` Tony Lindgren
2020-01-04 5:50 ` Tony Lindgren
2020-01-05 20:37 ` Tony Lindgren
2020-01-05 20:37 ` Tony Lindgren
2020-01-06 18:06 ` Matthijs van Duin
2020-01-06 18:06 ` Matthijs van Duin
2020-01-08 16:57 ` Tony Lindgren
2020-01-08 16:57 ` Tony Lindgren
2020-01-07 13:30 ` Tomi Valkeinen
2020-01-07 13:30 ` Tomi Valkeinen
2020-01-07 13:31 ` Tomi Valkeinen
2020-01-07 13:31 ` Tomi Valkeinen
2020-01-04 4:52 ` Matthijs van Duin [this message]
2020-01-04 4:52 ` Matthijs van Duin
2020-01-04 5:53 ` Tony Lindgren
2020-01-04 5:53 ` Tony Lindgren
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=20200104045211.GA10025@chinchilla \
--to=matthijsvanduin@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hns@goldelico.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-omap@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=sre@kernel.org \
--cc=tomi.valkeinen@ti.com \
--cc=tony@atomide.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.