All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Timur Kristóf" <timur.kristof@gmail.com>,
	"Marek Olšák" <maraeo@gmail.com>
Cc: "michael.jamet@intel.com" <michael.jamet@intel.com>,
	Mika Westerberg <mika.westerberg@linux.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: Thu, 18 Jul 2019 12:29:37 +0200	[thread overview]
Message-ID: <9d3e2499-e55d-c095-e73e-392440e2bf47@daenzer.net> (raw)
In-Reply-To: <8f0c2d7780430d40dd1e17a82484d236eae3f981.camel@gmail.com>

On 2019-07-18 11:06 a.m., Timur Kristóf wrote:
>>> Thanks Marek, I didn't know about that option.
>>> Tried it, here is the output: https://pastebin.com/raw/9SAAbbAA
>>>
>>> I'm not quite sure how to interpret the numbers, they are
>>> inconsistent
>>> with the results from both pcie_bw and amdgpu.benchmark, for
>>> example
>>> GTT->VRAM at a 128 KB is around 1400 MB/s (I assume that is
>>> megabytes /
>>> sec, right?).
>>
>> Based on the SDMA results, you have 2.4 GB/s. For 128KB, it's 2.2
>> GB/s for GTT->VRAM copies.
> 
> In the meantime I had a chat with Michel on IRC and he suggested that
> maybe amdgpu.benchmark=3 gives lower results because it uses a less
> than optimal way to do the benchmark.
> 
> Looking at the results from the mesa benchmark a bit more closely, I
> see that the SDMA can do:
> VRAM->GTT: 3087 MB/s = 24 Gbit/sec
> GTT->VRAM: 2433 MB/s = 19 Gbit/sec
> 
> So on Polaris at least, the SDMA is the fastest, and the other transfer
> methods can't match it. I also did the same test on Navi, where it's
> different: all other transfer methods are much closer to the SDMA, but
> the max speed is still around 20-24 Gbit / sec.
> 
> I still have a few questions:
> 
> 1. Why is the GTT->VRAM copy so much slower than the VRAM->GTT copy?
> 
> 2. Why is the bus limited to 24 Gbit/sec? I would expect the
> Thunderbolt port to give me at least 32 Gbit/sec for PCIe traffic.

That's unrealistic I'm afraid. As I said on IRC, from the GPU POV
there's an 8 GT/s x4 PCIe link, so ~29.8 Gbit/s (= 32 billion bit/s; I
missed this nuance on IRC) is the theoretical raw bandwidth. However, in
practice that's not achievable due to various overhead[0], and I'm only
seeing up to ~90% utilization of the theoretical bandwidth with a
"normal" x16 link as well. I wouldn't expect higher utilization without
seeing some evidence to suggest it's possible.


[0] According to
https://www.tested.com/tech/457440-theoretical-vs-actual-bandwidth-pci-express-and-thunderbolt/
, PCIe 3.0 uses 1.54% of the raw bandwidth for its internal encoding.
Also keep in mind all CPU<->GPU communication has to go through the PCIe
link, e.g. for programming the transfers, in-band signalling from the
GPU to the PCIe port where the data is being transferred to/from, ...

-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-07-18 10:29 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
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 [this message]
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=9d3e2499-e55d-c095-e73e-392440e2bf47@daenzer.net \
    --to=michel@daenzer.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=timur.kristof@gmail.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.