From: John Brooks <john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
"Marek Olšák" <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Christian König"
<deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: [PATCH v2] Visible VRAM Management Improvements
Date: Tue, 27 Jun 2017 22:33:16 -0400 [thread overview]
Message-ID: <1498617201-24557-1-git-send-email-john@fastquake.com> (raw)
Changes in this version:
- Dropped former patch 1 ("Separate placements and busy placements") as it was
no longer necessary
- Dropped former patch 4 ("Don't force BOs into visible VRAM if they can go to
GTT instead") as it was unnecessary and had too many side effects (Thanks
Christian)
- Dropped former patches 8 and 9 ("Asynchronously move BOs to visible VRAM" and
an associated optimization), as there may be better ways to address the root
of the problem
- Added a u64 cast to patch 1 (Thanks Christian)
- Optimized patch 2 in the case where visible VRAM is not smaller than total
VRAM (Thanks Michel)
The series as it is now fixes Dying Light and improves DiRT Rally frame times.
Without the asynchronous moves, there is still occasional stalling in DiRT
Rally.
The "Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS" patch received
objections, but I have not removed it yet as there seems to be some support for
the idea. The precise details of when to set and clear the flag may need further
discussion.
I note that if the patch is removed (but retaining the preventative measures
against repeated moves back and forth between GTT and invisible VRAM), there
are very few evictions but the average framerate drops from ~89 to ~82.
Presumably we'll see either higher memory presure or lower framerates depending
on whether userspace over- or under-estimates when to set this flag. What we do
in the kernel may depend on which side of this tradeoff we want to end up on
for now.
--
John Brooks (Frogging101)
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next reply other threads:[~2017-06-28 2:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 2:33 John Brooks [this message]
2017-06-28 2:33 ` [PATCH 1/5] drm/amdgpu: Add vis_vramlimit module parameter John Brooks
2017-06-28 2:33 ` [PATCH 2/5] drm/amdgpu: Throttle visible VRAM moves separately John Brooks
2017-06-28 2:33 ` [PATCH 3/5] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo John Brooks
2017-06-28 13:06 ` Christian König
[not found] ` <e3d7be62-e63b-f370-f159-147aaf8d7c50-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-28 22:59 ` John Brooks
2017-06-29 8:11 ` Christian König
[not found] ` <1498617201-24557-1-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-28 2:33 ` [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS John Brooks
[not found] ` <1498617201-24557-5-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-28 13:05 ` Christian König
2017-06-28 23:26 ` John Brooks
[not found] ` <20170628232639.GB11762-6hIufAJW0g7Gr8qjsLp7YGXnswh1EIUO@public.gmane.org>
2017-06-29 2:35 ` Michel Dänzer
2017-06-29 8:23 ` Christian König
2017-06-29 9:58 ` Michel Dänzer
2017-06-29 10:05 ` Daniel Vetter
[not found] ` <20170629100523.khsozocltct7tnfu-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2017-06-30 2:24 ` Michel Dänzer
[not found] ` <e1568d15-42da-4720-dff8-3a6e373f51d8-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-30 6:47 ` Christian König
[not found] ` <c9b732c1-4bdd-a2ce-1dc2-6abbaf89ce5a-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-30 12:39 ` Daniel Vetter
[not found] ` <20170630123904.afbsnmxkxxzuydr2-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2017-06-30 12:46 ` Christian König
2017-07-07 14:47 ` Marek Olšák
2017-06-30 1:56 ` John Brooks
[not found] ` <20170630015638.GA735-6hIufAJW0g7Gr8qjsLp7YGXnswh1EIUO@public.gmane.org>
2017-06-30 2:16 ` John Brooks
2017-06-29 3:18 ` Michel Dänzer
2017-06-28 2:33 ` [PATCH 5/5] drm/amdgpu: Don't force BOs into visible VRAM for page faults John Brooks
2017-06-29 2:30 ` Michel Dänzer
2017-06-29 2:33 ` [PATCH v2] Visible VRAM Management Improvements Michel Dänzer
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=1498617201-24557-1-git-send-email-john@fastquake.com \
--to=john-xq/ko7c6e2bl57midrcfdg@public.gmane.org \
--cc=airlied-cv59FeDIM0c@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=michel-otUistvHUpPR7s880joybQ@public.gmane.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;
as well as URLs for NNTP newsgroup(s).