Bug 97882 - [amdgpu SI] amdgpu on SI devices is much slower then radeon
Summary: [amdgpu SI] amdgpu on SI devices is much slower then radeon
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-21 00:48 UTC by Trevor Davenport
Modified: 2017-08-01 02:21 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (70.62 KB, text/plain)
2016-09-21 00:48 UTC, Trevor Davenport
Details
Xorg.0.log (45.62 KB, text/x-log)
2016-09-21 00:49 UTC, Trevor Davenport
Details
dmesg | egrep 'drm|amdgpu' (4.20 KB, text/plain)
2017-05-22 14:33 UTC, Maxim Sheviakov
Details
dmesg | egrep 'drm|radeon' (5.52 KB, text/plain)
2017-05-22 15:07 UTC, Maxim Sheviakov
Details

Description Trevor Davenport 2016-09-21 00:48:13 UTC
Created attachment 126682 [details]
dmesg

AMDGPU on SI devices appears to be much slower then radeon currently is.  

For example, Unigine Heaven 4.0:
   AMDGPU FPS:18.3 Score:460 Min FPS:9.5 Max FPS:46.1
   RADEON FPS:38.4 Score:967 Min FPS:7.5 Max FPS:83.5

Reading /sys/kernel/debug/dri/0/radeon_pm_info both report the same values:
   uvd    vclk: 0 dclk: 0
   power level 3    sclk: 105000 mclk: 140000 vddc: 1206 vddci: 1025 pcie gen: 2
Comment 1 Trevor Davenport 2016-09-21 00:49:15 UTC
Created attachment 126683 [details]
Xorg.0.log
Comment 2 Trevor Davenport 2016-09-21 00:53:43 UTC
The above numbers where using the modesetting driver since I was trying to keep as much the same between radeon and amdgpu.  I get similar behavior from amdgpu though.

Both radeon and amdgpu built from commit:
   https://cgit.freedesktop.org/~agd5f/linux/
   drm-next-4.9-wip
   
   commit 25114c509cc39b387aa358a86fa48c855266a6fe
   Author: Alex Deucher <alexander.deucher@amd.com>
   Date:   Wed Sep 14 14:15:34 2016 -0400

       drm/radeon/atif: Send a hotplug event when we get dgpu display request


Mesa:
   commit 6b0ba02cae1526d6e6671a9ff620fd3bd7d4d032

llvm:
   commit 338f974b6e4f5d5d004d36d0d446289280d0c372

drm:
   commit 2d00869599a1c853238401a38a334c3bc8673343
Comment 3 Maxim Sheviakov 2017-05-22 14:27:12 UTC
Same here. Using Arch x86_64 with linux-ck 4.11.2 and mesa 17.1.0. AMDGPU's performance is about 60~70% of radeon's on MSI R7 370 Armor 2X.
Comment 4 Maxim Sheviakov 2017-05-22 14:33:55 UTC
Created attachment 131435 [details]
dmesg | egrep 'drm|amdgpu'
Comment 5 Maxim Sheviakov 2017-05-22 15:07:46 UTC
Created attachment 131436 [details]
dmesg | egrep 'drm|radeon'
Comment 6 Trevor Davenport 2017-05-22 15:22:29 UTC
From phoronix's data this appears to not happen on Tahiti chips.  The 270x and 370 are always slower on amdgpu compared to radeon.

See http://www.phoronix.com/scan.php?page=article&item=linux-411-gcn10&num=2
Comment 7 Trevor Davenport 2017-08-01 02:18:49 UTC
This is fixed by the following commit:


author	Jean Delvare <jdelvare@suse.de>	2017-07-30 08:18:25 (GMT)
committer	Alex Deucher <alexander.deucher@amd.com>	2017-07-31 20:30:42 (GMT)
commit	e5c8d400da67abc1c033b9a4af1806926b55e5f6 (patch)
tree	cf3dac459890ed900416d4087ae0603d4aa42b6f
parent	29805b5f60d88c56ae7e91ae231f0ff8bf1983b8 (diff)

drm/amdgpu: Fix undue fallthroughs in golden registers initialization

As I was staring at the si_init_golden_registers code, I noticed that
the Pitcairn initialization silently falls through the Cape Verde
initialization, and the Oland initialization falls through the Hainan
initialization. However there is no comment stating that this is
intentional, and the radeon driver doesn't have any such fallthrough,
so I suspect this is not supposed to happen.

Commit can be seen here:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.14-wip&id=e5c8d400da67abc1c033b9a4af1806926b55e5f6

With this fix I now get performance approximately equal to that of radeon.


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.