dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Timur Kristóf" <timur.kristof@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Alex Deucher" <alexdeucher@gmail.com>
Cc: "michael.jamet@intel.com" <michael.jamet@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?
Date: Fri, 05 Jul 2019 11:17:47 +0200	[thread overview]
Message-ID: <e119b38bdb0859c3eb826af30487ac01278f59fd.camel@gmail.com> (raw)
In-Reply-To: <eee4eea0-ad27-9d05-192d-c1207da5d0bc@daenzer.net>


> > Can you point me to the place where amdgpu decides the PCIe link
> > speed?
> > I'd like to try to tweak it a little bit to see if that helps at
> > all.
> 
> I'm not sure offhand, Alex or anyone?

Thus far, I started by looking at how the pp_dpm_pcie sysfs interface
works, and found smu7_hwmgr which seems to be the only hwmgr that
actually outputs anything on PP_PCIE:
https://github.com/torvalds/linux/blob/a2d635decbfa9c1e4ae15cb05b68b2559f7f827c/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c#L4462

However, its output is definitely incorrect. It tells me that the
supported PCIe modes are:
cat /sys/class/drm/card1/device/pp_dpm_pcie 
0: 2.5GT/s, x8 
1: 8.0GT/s, x16

It allows me to change between these two modes, but the change doesn't
seem to have any actual effect on the transfer speeds.

Neither of those modes actually makes sense. Amdgpu doesn't seem to be
aware of the fact that it runs on a x4 link. In fact, the
smu7_get_current_pcie_lane_number function even has an assertion:
PP_ASSERT_WITH_CODE((7 >= link_width),

On the other hand:
cat /sys/class/drm/card1/device/current_link_width
4

So I don't understand how it can even work with PCIe x4, why doesn't
that assertion get triggered on my system?

> > Out of curiosity, is there a performace decrease with small
> > transfers
> > on a "normal" PCIe port too, or is this specific to TB3?
> 
> It's not TB3 specific. With a "normal" 8 GT/s x16 port, I get between
> ~256 MB/s for 4 KB transfers and ~12 GB/s for 4 MB transfers (even
> larger transfers seem slightly slower again). This also looks
> consistent
> with your measurements in that the practical limit seems to be around
> 75% of the theoretical bandwidth.

Sounds like your idea to try to optimize mesa to use larger transfers
is a good idea, then.

Best regards,
Tim

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-07-05  9:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 10:23 Why is Thunderbolt 3 limited to 2.5 GT/s on Linux? Timur Kristóf
2019-06-28 10:32 ` Mika Westerberg
2019-06-28 11:08   ` Timur Kristóf
2019-06-28 11:34     ` Mika Westerberg
2019-06-28 12:21       ` Timur Kristóf
2019-06-28 12:53         ` Mika Westerberg
2019-06-28 13:33           ` Timur Kristóf
2019-06-28 14:14             ` Mika Westerberg
2019-06-28 14:53               ` Timur Kristóf
2019-07-01 11:44                 ` Mika Westerberg
2019-07-01 14:25                   ` Timur Kristóf
2019-07-01 14:28         ` Alex Deucher
2019-07-01 14:38           ` Timur Kristóf
2019-07-01 14:46             ` Alex Deucher
2019-07-01 15:10               ` Mika Westerberg
2019-07-01 14:54         ` Michel Dänzer
2019-07-01 16:01           ` Timur Kristóf
2019-07-02  8:09             ` Michel Dänzer
2019-07-02  9:49               ` Timur Kristóf
2019-07-03  8:07                 ` Michel Dänzer
2019-07-03 11:04                   ` Timur Kristóf
2019-07-04  8:26                     ` Michel Dänzer
2019-07-05  9:17                       ` Timur Kristóf [this message]
2019-07-05 13:36                       ` Alex Deucher
2019-07-18  9:11                         ` Timur Kristóf
2019-07-18 13:50                           ` Alex Deucher
     [not found]                             ` <172a41d97d383a8989ebd213bb4230a2df4d636d.camel@gmail.com>
2019-07-19 14:29                               ` Alex Deucher
2019-07-03 18:44                   ` Marek Olšák
2019-07-05  9:27                     ` Timur Kristóf
2019-07-05 15:35                       ` Marek Olšák
2019-07-05 16:01                         ` Timur Kristóf
     [not found]                         ` <8f0c2d7780430d40dd1e17a82484d236eae3f981.camel@gmail.com>
2019-07-18 10:29                           ` Michel Dänzer
2019-07-22  9:39                             ` Timur Kristóf
2019-07-23  8:11                               ` 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=e119b38bdb0859c3eb826af30487ac01278f59fd.camel@gmail.com \
    --to=timur.kristof@gmail.com \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michael.jamet@intel.com \
    --cc=michel@daenzer.net \
    --cc=mika.westerberg@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox