Bug 88227 - Radeonsi: High GTT usage in Prison Architect large map
Summary: Radeonsi: High GTT usage in Prison Architect large map
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2015-01-09 09:16 UTC by James Harvey
Modified: 2015-01-20 03:35 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

dmesg (64.61 KB, text/plain)
2015-01-09 09:16 UTC, James Harvey
no flags Details
xorg.log (49.96 KB, text/plain)
2015-01-09 09:16 UTC, James Harvey
no flags Details
Game log with R600_DEBUG=cs (3.57 KB, text/plain)
2015-01-09 09:17 UTC, James Harvey
no flags Details
Gallium hud on small map (46.27 KB, image/png)
2015-01-09 09:18 UTC, James Harvey
no flags Details
Gallium hud on large map (179.69 KB, image/png)
2015-01-09 09:18 UTC, James Harvey
no flags Details
large map prior to commit 150ac07b (96.45 KB, image/png)
2015-01-11 07:08 UTC, James Harvey
no flags Details

Description James Harvey 2015-01-09 09:16:09 UTC
Created attachment 111992 [details]

Poor performace in Prison Architect (version alpha-28) when trying to play on the large map setting.  Small map is smooth, Gallium hud showing 60fps.  A new game with a large map (empty, nothing constructed) has about 0fps and high GTT usage while zoomed out.  Zooming in fairly close on the large map shows a decrease in GTT use and fps increases.

Kernel is linux-3.19.0-rc3
Running git versions of the following packages (updated Jan 08):
libdrm 566c3ce877a4be72697e15cdfc421ce965f7c37d
llvm c41acffe2297585ad56aa772de75e82c132070bb
xf86-video-ati 04da199231bb3f11cf17f94574a8df05855a7b82
mesa 3d8188d4f898afcf4f181de29e12c5b218bbd393

dmesg shows two errors:
[ 5665.586842] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -12!
[ 5750.747498] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-512)

R600_DEBUG=cs shows:
radeon: The kernel rejected CS, see dmesg for more information.
R600_DEBUG=nodma seemed to have no effect.

Logs and gallium hud screenshots attached.  Just picked up this game, so not sure if there is a regression involved.  Will try some older kernels and mesa.
Comment 1 James Harvey 2015-01-09 09:16:52 UTC
Created attachment 111993 [details]
Comment 2 James Harvey 2015-01-09 09:17:28 UTC
Created attachment 111994 [details]
Game log with R600_DEBUG=cs
Comment 3 James Harvey 2015-01-09 09:18:08 UTC
Created attachment 111995 [details]
Gallium hud on small map
Comment 4 James Harvey 2015-01-09 09:18:54 UTC
Created attachment 111996 [details]
Gallium hud on large map
Comment 5 Michel Dänzer 2015-01-09 09:24:48 UTC
Does radeon.gartsize=2048 on the kernel command line help?
Comment 6 James Harvey 2015-01-09 10:13:12 UTC
Unfortunately, it did not help.
Seems like the fps drops occurs whenever the requested GTT gets above
about 515-520mb or so.
Comment 7 James Harvey 2015-01-10 12:00:29 UTC
Further testing shows large fps drops from 60 to ~0 whenever used GTT exceeds 550mb.  Tested kernels going back to 3.10.63 with no improvement.

Installed kernel 3.19.0-rc3 and llvm-3.4.2 to test mesa releases.

Confirmed this is a regression in mesa.  Mesa-10.0.4, 10.3.5 and 10.3.6 manage at least 30fps or higher with GTT usage over 550mb.

Tested Mesa 10.4.1 and Mesa git master, both are effected by this issue.  Looks like it was introduced in the 10.4 branch.  Attempting to bisect.
Comment 8 James Harvey 2015-01-11 07:08:15 UTC
Created attachment 112085 [details]
large map prior to commit 150ac07b

Bisect complete:

150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 is the first bad commit
commit 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jun 25 18:36:43 2014 +0900

    r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers
    Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Prior to this commit, there is a slight fps drop (60->24) while moving around the map for the first time, but thereafter it stays at roughly 60fps.
Comment 9 James Harvey 2015-01-11 14:40:20 UTC
Reverting the above commit against mesa git master did not solve the problem.
Performed another bisection and got result:

commit b419c651fbbf3660d7b53623dfa2e5a4c9bd3b98
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Wed Aug 20 23:53:40 2014 +0200

    gallium/pb_bufmgr_cache: limit the size of cache
    This should make a machine which is running piglit more responsive at times.
    e.g. streaming-texture-leak can easily eat 600 MB because of how fast it
    creates new textures.

Reverting this commit (to remove the cache limit) returned the game to full performance. Tested against git-ff1948a.
Comment 10 Marek Olšák 2015-01-11 15:00:28 UTC
James, can you increase the size of cache manually and see what works better? There is only one formula in radeon_drm_winsys.c:676, so it should be trivial.

Also please how much VRAM and GTT do you have?
Comment 11 James Harvey 2015-01-12 03:31:28 UTC
Hello Marek,

My memory info:
[    1.879493] [drm] radeon: 2048M of VRAM memory ready
[    1.879494] [drm] radeon: 2048M of GTT memory ready.

I also have 8gb of system memory. I patched radeon_drm_winsys.c as per your suggestion. This seemed to work well:

- (ws->info.vram_size + ws->info.gart_size) / 8);
+ (ws->info.vram_size + ws->info.gart_size) / 2);

I tried changing the divisor to 4, but that didn't help much.
Divisor at 3 was better but still had some fps drops to zero and trouble getting above about 40fps.
Divisor at 2 was much better, fps drops only when waiting for data to load in memory. (such as suddenly zooming out or saving/loading game).

While testing, the maximum GTT usage I saw was 1.82gb, with typical usage around 1-1.5gb depending on how closely the map was zoomed in. Vram usage is pretty flat, usually around 450mb.
Comment 12 Michel Dänzer 2015-01-20 03:35:45 UTC
Module: Mesa
Branch: master
Commit: ccc5b60b06269a5d847b7fe9ebe08dc61b4d2030
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=ccc5b60b06269a5d847b7fe9ebe08dc61b4d2030

Author: Marek Olšák <marek.olsak@amd.com>
Date:   Mon Jan 12 14:35:24 2015 +0100

winsys/radeon: increase the size of buffer cache

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.