From: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
To: Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Michael Jamet
<michael.jamet-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Amir Levy <amir.jer.levy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Darren Hart <dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Mika Westerberg
<mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
Christian Koenig <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
Andy Shevchenko <andy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH 1/5] PCI: Recognize Thunderbolt devices
Date: Sat, 4 Mar 2017 12:14:46 +0100 [thread overview]
Message-ID: <20170304111446.GB3143@wunner.de> (raw)
In-Reply-To: <20170224221724.GA26430-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> > Detect on probe whether a PCI device is part of a Thunderbolt controller.
[...]
> > * If an external Thunderbolt GPU is connected to a dual GPU laptop (Mac
> > or not), that GPU is currently registered with vga_switcheroo even
> > though it can neither drive the laptop's panel nor be powered off by
> > the platform. To vga_switcheroo it will appear as if two discrete
> > GPUs are present. As a result, when the external GPU is runtime
> > suspended, vga_switcheroo will cut power to the internal discrete GPU
> > which may not be runtime suspended at all at this moment. The
> > solution is to not register external GPUs with vga_switcheroo, which
> > necessitates a way to recognize if they're on a Thunderbolt daisy
> > chain.
>
> If I understand correctly, vga_switcheroo manages two GPUs that have a
> single output: either there's a mux that connects one GPU or the other
> to the output, or one GPU is permanently connected to the output and
> the other does offline rendering.
There are two aspects to hybrid graphics, switching the panel between
GPUs and powering off the discrete GPU. (Some laptops can also switch
external DP ports between GPUs and some, as you say, cannot switch the
panel and only use the discrete GPU for render offloading.)
> To this non-GPU person, it sounds like the important question is
> whether two GPUs are related in this way (either they feed the same
> mux, or there's some special offline rendering connection between
> them). That sounds unrelated to the question of how the GPUs
> themselves are connected to the PCI hierarchy.
To the best of my knowledge there's no definite way to determine whether
two GPUs are connected to the same panel via a mux.
There is also no such thing as a special render offloading connection:
Frames are computed on a discrete GPU, then copied over PCIe into the
framebuffer of the integrated GPU. Whether that discrete GPU is
on-board or externally connected is completely transparent and not
discernible other than by looking at the PCI hierarchy.
The same issue exists for HD Audio controllers integrated into many
discrete GPUs: To the OS these look like separate PCI functions
and in sound/pci/hda/hda_intel.c:get_bound_vga() we leverage the fact
that the GPU is always function 0 and the HD Audio is function 1 to
discover the GPU corresponding to a particular HD Audio controller.
So again that relationship is deduced from the PCI hierarchy.
> From a pure PCI perspective, I assume it would be conceivable to have
> two Thunderbolt-connected GPUs feeding into a mux. Or to have a GPU
> (unrelated to the mux) in a non-Thunderbolt plugin slot or connected
> externally via a non-Thunderbolt switch and an iPass cable.
Technically such products would be possible, but I believe they don't
exist. (Unlike Thunderbolt eGPUs, which have been on the market for
a few years.)
Thanks,
Lukas
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2017-03-04 11:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 19:19 [PATCH 0/5] Thunderbolt GPU fixes Lukas Wunner
[not found] ` <cover.1487938188.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2017-02-24 19:19 ` [PATCH 1/5] PCI: Recognize Thunderbolt devices Lukas Wunner
2017-02-24 22:17 ` Bjorn Helgaas
2017-02-25 7:40 ` Lukas Wunner
2017-02-25 14:44 ` Bjorn Helgaas
[not found] ` <20170224221724.GA26430-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-03-04 11:14 ` Lukas Wunner [this message]
2017-02-24 19:19 ` [PATCH 2/5] apple-gmux: Don't switch external DP port on 2011+ MacBook Pros Lukas Wunner
2017-03-09 15:03 ` [PATCH 0/5] Thunderbolt GPU fixes Daniel Vetter
[not found] ` <20170309150347.a4k4w2sclox2365t-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2017-03-10 12:07 ` Lukas Wunner
2017-03-10 12:15 ` Andy Shevchenko
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=20170304111446.GB3143@wunner.de \
--to=lukas-jfq808j9c/izqb+pc5nmwq@public.gmane.org \
--cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=amir.jer.levy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=andy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=michael.jamet-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=platform-driver-x86-u79uwXL29TY76Z2rM5mHXA@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