From: John Keeping <john@metanate.com>
To: Bert Schiettecatte <bert@noisetron.com>,
Rob Herring <robh@kernel.org>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Steven Price <steven.price@arm.com>,
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: dri/drm/kms question with regards to minor faults
Date: Fri, 29 Oct 2021 16:33:32 +0100 [thread overview]
Message-ID: <YXwUTPBPlgwj5NdA@donbot> (raw)
In-Reply-To: <e9e2bbf8-daa3-48f0-b875-f7487b64d57c@www.fastmail.com>
Hi Bert,
On Tue, Oct 26, 2021 at 05:18:47PM -0700, Bert Schiettecatte wrote:
> I have an application I'm working on where I'm using OpenGLES / EGL
> and dri/drm/kms. The main loop of my application looks like the code
> below. When running htop, I see that the number of minor faults
> (memory) are increasing over time at a rate of about 500 per second,
> due to the code below. Is this normal and something to worry about,
> and is there a way to get rid of the minor faults? I'm on the rockchip
> rk3288 platform. The faults do not come from my OpenGLES code.
Coincidentally, I've been looking at Panfrost on RK3288 this week as
well! I'm testing it with a project that has been using the binary blob
driver for several years and unfortunately Panfrost seems to use ~15%
more CPU.
Like you, I see a huge number of minor faults (~500/second compared with
~3/second on libmali). It seems that Panfrost is mmap'ing and
munmap'ing buffers on every frame which doesn't happen when the same
application is using the binary driver.
I've testing Linux 5.10.76 and 5.15-rc7 along with Mesa 20.3.5, 21.1.8
and main (as of 704340f0f67) and there's no real difference in
performance across any of those.
Panfrost experts, is there a missed opportunity for optimisation here?
Or is there something applications should be doing differently to avoid
repeatedly mapping & unmapping the same buffers?
Thanks,
John
next prev parent reply other threads:[~2021-10-29 15:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 0:18 dri/drm/kms question with regards to minor faults Bert Schiettecatte
2021-10-29 15:33 ` John Keeping [this message]
2021-11-01 5:20 ` Bert Schiettecatte
2021-11-03 11:54 ` Steven Price
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=YXwUTPBPlgwj5NdA@donbot \
--to=john@metanate.com \
--cc=alyssa.rosenzweig@collabora.com \
--cc=bert@noisetron.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=robh@kernel.org \
--cc=steven.price@arm.com \
--cc=tomeu.vizoso@collabora.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.