Nouveau - Aug 2019 - [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

> -----Original Message-----
> From: Karol Herbst <kherbst at redhat.com>
> Sent: Thursday, August 15, 2019 9:25 AM
> To: Limonciello, Mario
> Cc: Dave Airlie; LKML; Linux ACPI Mailing List; dri-devel; nouveau; Rafael
J .
> Wysocki; Alex Hung; Ben Skeggs; David Airlie
> Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI
string to
> enable dGPU direct output"
> 
> 
> [EXTERNAL EMAIL]
> 
> On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at dell.com>
wrote:
> >
> > > > There are definitely going to be regressions on machines in
the field with
> the
> > > > in tree drivers by reverting this.  I think we should have
an answer for all of
> > > those
> > > > before this revert is accepted.
> > > >
> > > > Regarding systems with Intel+NVIDIA, we'll have to work
with partners to
> > > collect
> > > > some information on the impact of reverting this.
> > > >
> > > > When this is used on a system with Intel+AMD the ASL
configures AMD
> GPU to
> > > use
> > > > "Hybrid Graphics" when on Windows and "Power
Express" and "Switchable
> > > Graphics"
> > > > when on Linux.
> > >
> > > and what's exactly the difference between those? And
what's the actual
> > > issue here?
> >
> > DP/HDMI is not detected unless plugged in at bootup.  It's due to
missing HPD
> > events.
> >
> 
> afaik Lyude was working on fixing all that, at least for some drivers.
> If there is something wrong, we still should fix the drivers, not
> adding ACPI workarounds.
I don't disagree, but timing is frequently a limitation if you want the
hardware to
work when you put it on the market.

The whole idea behind the OSI string was that it could be reverted when the time
was right.  From this discussion it very well may be for systems with AMD GPU,
but
it needs to be checked again.
> 
> Alex: do you know if there are remaining issues regarding that with amdgpu?
> 
> > >
> > > We already have the PRIME offloading in place and if that's
not
> > > enough, we should work on extending it, not adding some ACPI
based
> > > workarounds, because that's exactly how that looks like.
> > >
> > > Also, was this discussed with anybody involved in the drm
subsystem?
> > >
> > > >
> > > > I feel we need a knob and/or DMI detection to affect the
changes that the
> ASL
> > > > normally performs.
> > >
> > > Why do we have to do that on a firmware level at all?
> >
> > Folks from AMD Graphics team recommended this approach.  
I should clarify this is from the folks on AMD graphics team that interact to
OEMs
like Dell which are not necessarily the same folks who work on the drivers
directly.
> From their perspective
> > it's not a workaround.  They view this as a different architecture
for AMD
> graphics driver on
> > Windows and AMD graphics w/ amdgpu driver.  They have different ASL
paths
> used for
> > each.
> 
> @alex: is this true?

On Thu, Aug 15, 2019 at 4:34 PM <Mario.Limonciello at dell.com>
wrote:
>
> > -----Original Message-----
> > From: Karol Herbst <kherbst at redhat.com>
> > Sent: Thursday, August 15, 2019 9:25 AM
> > To: Limonciello, Mario
> > Cc: Dave Airlie; LKML; Linux ACPI Mailing List; dri-devel; nouveau;
Rafael J .
> > Wysocki; Alex Hung; Ben Skeggs; David Airlie
> > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM
_OSI string to
> > enable dGPU direct output"
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at dell.com>
wrote:
> > >
> > > > > There are definitely going to be regressions on
machines in the field with
> > the
> > > > > in tree drivers by reverting this.  I think we should
have an answer for all of
> > > > those
> > > > > before this revert is accepted.
> > > > >
> > > > > Regarding systems with Intel+NVIDIA, we'll have to
work with partners to
> > > > collect
> > > > > some information on the impact of reverting this.
> > > > >
> > > > > When this is used on a system with Intel+AMD the ASL
configures AMD
> > GPU to
> > > > use
> > > > > "Hybrid Graphics" when on Windows and
"Power Express" and "Switchable
> > > > Graphics"
> > > > > when on Linux.
> > > >
> > > > and what's exactly the difference between those? And
what's the actual
> > > > issue here?
> > >
> > > DP/HDMI is not detected unless plugged in at bootup.  It's
due to missing HPD
> > > events.
> > >
> >
> > afaik Lyude was working on fixing all that, at least for some drivers.
> > If there is something wrong, we still should fix the drivers, not
> > adding ACPI workarounds.
>
> I don't disagree, but timing is frequently a limitation if you want the
hardware to
> work when you put it on the market.
>
> The whole idea behind the OSI string was that it could be reverted when the
time
> was right.  From this discussion it very well may be for systems with AMD
GPU, but
> it needs to be checked again.
>
> >
> > Alex: do you know if there are remaining issues regarding that with
amdgpu?
> >
> > > >
> > > > We already have the PRIME offloading in place and if
that's not
> > > > enough, we should work on extending it, not adding some ACPI
based
> > > > workarounds, because that's exactly how that looks like.
> > > >
> > > > Also, was this discussed with anybody involved in the drm
subsystem?
> > > >
> > > > >
> > > > > I feel we need a knob and/or DMI detection to affect
the changes that the
> > ASL
> > > > > normally performs.
> > > >
> > > > Why do we have to do that on a firmware level at all?
> > >
> > > Folks from AMD Graphics team recommended this approach.
>
> I should clarify this is from the folks on AMD graphics team that interact
to OEMs
> like Dell which are not necessarily the same folks who work on the drivers
directly.
>
yeah, I understand the pressure, and it might have been fine if we
would have this discussion upstream, if it's about pushing things
upstream. The commits itself didn't even make the impression that
anybody with the drm drivers involved even looked at those patches and
this is the worst part of those commits.
> > From their perspective
> > > it's not a workaround.  They view this as a different
architecture for AMD
> > graphics driver on
> > > Windows and AMD graphics w/ amdgpu driver.  They have different
ASL paths
> > used for
> > > each.
> >
> > @alex: is this true?