Re: Stupid NVIDIA 3D vgaarb.c patch

Re: Stupid NVIDIA 3D vgaarb.c patch

[Linus Torvalds]

Adding proper people and mailing lists..

The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
appropriate, but hopefully somebody does. The fact that it makes
things work certainly argues fairly convincingly for it, but I want
some backup here.

Dave, BenH?

Christopher(?), can you please also specify which laptop etc. And the
patch itself seems to have come from somebody else, unless you're
Lekensteyn. So we'd want to get the provenance of that too.

                Linus

On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> Hi Linus,
>
> I don't know who the original author is and I can have one of the distro
> graphics friends review it, but I need this patch below to get NVIDIA
> drivers to work (without using any Intel graphics) on my laptop
> http://pastebin.com/wpmFi38k
>
> Sorry - I know this is not the proper way to submit a patch, but it's
> trivial and I'm not a kernel dev.
>
> Thanks
>
> ./C
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stupid NVIDIA 3D vgaarb.c patch

[Linus Torvalds]

Adding proper people and mailing lists..

The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
appropriate, but hopefully somebody does. The fact that it makes
things work certainly argues fairly convincingly for it, but I want
some backup here.

Dave, BenH?

Christopher(?), can you please also specify which laptop etc. And the
patch itself seems to have come from somebody else, unless you're
Lekensteyn. So we'd want to get the provenance of that too.

                Linus

On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> Hi Linus,
>
> I don't know who the original author is and I can have one of the distro
> graphics friends review it, but I need this patch below to get NVIDIA
> drivers to work (without using any Intel graphics) on my laptop
> http://pastebin.com/wpmFi38k
>
> Sorry - I know this is not the proper way to submit a patch, but it's
> trivial and I'm not a kernel dev.
>
> Thanks
>
> ./C

Re: Stupid NVIDIA 3D vgaarb.c patch

[C Bergström]

[-- Attachment #1.1: Type: text/plain, Size: 1506 bytes --]

Here's where I originally found it
https://github.com/Bumblebee-Project/Bumblebee/issues/159
(Adding Peter to cc chain)

I guess there's already a bug id and some (snarky?) comments
https://bugzilla.kernel.org/show_bug.cgi?id=63641
-------
This is for Aorus X3 laptop with NVIDIA GTX 870m card

On Tue, Sep 23, 2014 at 3:43 AM, Linus Torvalds <
torvalds@linux-foundation.org> wrote:

> Adding proper people and mailing lists..
>
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> things work certainly argues fairly convincingly for it, but I want
> some backup here.
>
> Dave, BenH?
>
> Christopher(?), can you please also specify which laptop etc. And the
> patch itself seems to have come from somebody else, unless you're
> Lekensteyn. So we'd want to get the provenance of that too.
>
>                 Linus
>
> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
> wrote:
> > Hi Linus,
> >
> > I don't know who the original author is and I can have one of the distro
> > graphics friends review it, but I need this patch below to get NVIDIA
> > drivers to work (without using any Intel graphics) on my laptop
> > http://pastebin.com/wpmFi38k
> >
> > Sorry - I know this is not the proper way to submit a patch, but it's
> > trivial and I'm not a kernel dev.
> >
> > Thanks
> >
> > ./C
>

[-- Attachment #1.2: Type: text/html, Size: 2365 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: Stupid NVIDIA 3D vgaarb.c patch

[Peter Wu]

On Tuesday 23 September 2014 03:52:48 C Bergström wrote:
> Here's where I originally found it
> https://github.com/Bumblebee-Project/Bumblebee/issues/159
> (Adding Peter to cc chain)
> 
> I guess there's already a bug id and some (snarky?) comments
> https://bugzilla.kernel.org/show_bug.cgi?id=63641
> -------
> This is for Aorus X3 laptop with NVIDIA GTX 870m card
> 
> On Tue, Sep 23, 2014 at 3:43 AM, Linus Torvalds <
> torvalds@linux-foundation.org> wrote:
> 
> > Adding proper people and mailing lists..
> >
> > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> > appropriate, but hopefully somebody does. The fact that it makes
> > things work certainly argues fairly convincingly for it, but I want
> > some backup here.
> >
> > Dave, BenH?
> >
> > Christopher(?), can you please also specify which laptop etc. And the
> > patch itself seems to have come from somebody else, unless you're
> > Lekensteyn. So we'd want to get the provenance of that too.

If I understood this correctly, VGA arbitration is used to deal with multiple
users of a fixed IO memory address. I don't know whether modern software still
use it, but if they do, then it probably makes sense to include the 3D
controller class as some Nvidia graphics card are configured with this class.

Unfortunately I cannot provide more details than this as I don't know the
specifics. Feel free to take this patch and make it suitable for inclusion. I
don't have this kind of hardware, but mr. C is certainly not the only one with
this.

Kind regards,
Peter

> >                 Linus
> >
> > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
> > wrote:
> > > Hi Linus,
> > >
> > > I don't know who the original author is and I can have one of the distro
> > > graphics friends review it, but I need this patch below to get NVIDIA
> > > drivers to work (without using any Intel graphics) on my laptop
> > > http://pastebin.com/wpmFi38k
> > >
> > > Sorry - I know this is not the proper way to submit a patch, but it's
> > > trivial and I'm not a kernel dev.
> > >
> > > Thanks
> > >
> > > ./C
> >

-- 
Kind regards,
Peter
https://lekensteyn.nl

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Williamson]

On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> Adding proper people and mailing lists..
> 
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> things work certainly argues fairly convincingly for it, but I want
> some backup here.
> 
> Dave, BenH?

TBH, it seems pretty dubious to me.  There's nothing in the spec that
would give us reason to believe that a device with a 3D controller class
code requires VGA arbitration.  Also, if this controller starts
participating in arbitration then this same laptop will likely disable
DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
MMIO space.  I'm not sure what the solution is, but unfortunately it's
likely to be much more complicated than this patch.  Thanks,

Alex

> Christopher(?), can you please also specify which laptop etc. And the
> patch itself seems to have come from somebody else, unless you're
> Lekensteyn. So we'd want to get the provenance of that too.
> 
>                 Linus
> 
> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> > Hi Linus,
> >
> > I don't know who the original author is and I can have one of the distro
> > graphics friends review it, but I need this patch below to get NVIDIA
> > drivers to work (without using any Intel graphics) on my laptop
> > http://pastebin.com/wpmFi38k
> >
> > Sorry - I know this is not the proper way to submit a patch, but it's
> > trivial and I'm not a kernel dev.
> >
> > Thanks
> >
> > ./C



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

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Williamson]

On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> Adding proper people and mailing lists..
> 
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> things work certainly argues fairly convincingly for it, but I want
> some backup here.
> 
> Dave, BenH?

TBH, it seems pretty dubious to me.  There's nothing in the spec that
would give us reason to believe that a device with a 3D controller class
code requires VGA arbitration.  Also, if this controller starts
participating in arbitration then this same laptop will likely disable
DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
MMIO space.  I'm not sure what the solution is, but unfortunately it's
likely to be much more complicated than this patch.  Thanks,

Alex

> Christopher(?), can you please also specify which laptop etc. And the
> patch itself seems to have come from somebody else, unless you're
> Lekensteyn. So we'd want to get the provenance of that too.
> 
>                 Linus
> 
> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> > Hi Linus,
> >
> > I don't know who the original author is and I can have one of the distro
> > graphics friends review it, but I need this patch below to get NVIDIA
> > drivers to work (without using any Intel graphics) on my laptop
> > http://pastebin.com/wpmFi38k
> >
> > Sorry - I know this is not the proper way to submit a patch, but it's
> > trivial and I'm not a kernel dev.
> >
> > Thanks
> >
> > ./C

Re: Stupid NVIDIA 3D vgaarb.c patch

[C Bergström]

[-- Attachment #1.1: Type: text/plain, Size: 2166 bytes --]

For clarity - My testing and the patch is required when the Intel driver
isn't being used at all. After I finish some other testing I can see if
bumblebee and intel driver + this patch will play nicely.

How is a laptop with dual VGA controllers any different than if one
identifies itself as a "3D controller"?

On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson <alex.williamson@redhat.com
> wrote:

> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> > Adding proper people and mailing lists..
> >
> > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> > appropriate, but hopefully somebody does. The fact that it makes
> > things work certainly argues fairly convincingly for it, but I want
> > some backup here.
> >
> > Dave, BenH?
>
> TBH, it seems pretty dubious to me.  There's nothing in the spec that
> would give us reason to believe that a device with a 3D controller class
> code requires VGA arbitration.  Also, if this controller starts
> participating in arbitration then this same laptop will likely disable
> DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
> MMIO space.  I'm not sure what the solution is, but unfortunately it's
> likely to be much more complicated than this patch.  Thanks,
>
> Alex
>
> > Christopher(?), can you please also specify which laptop etc. And the
> > patch itself seems to have come from somebody else, unless you're
> > Lekensteyn. So we'd want to get the provenance of that too.
> >
> >                 Linus
> >
> > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
> wrote:
> > > Hi Linus,
> > >
> > > I don't know who the original author is and I can have one of the
> distro
> > > graphics friends review it, but I need this patch below to get NVIDIA
> > > drivers to work (without using any Intel graphics) on my laptop
> > > http://pastebin.com/wpmFi38k
> > >
> > > Sorry - I know this is not the proper way to submit a patch, but it's
> > > trivial and I'm not a kernel dev.
> > >
> > > Thanks
> > >
> > > ./C
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2931 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Williamson]

On Tue, 2014-09-23 at 04:20 +0700, C Bergström wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
> 
> How is a laptop with dual VGA controllers any different than if one
> identifies itself as a "3D controller"?

With dual VGA controllers, we can change VGA routing in the chipset so
that we can address one device or the other using the VGA address space.
This lets things like Xorg switch between cards to initialize a card via
the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
reports itself as a 3D controller, then we have no reason to believe
that the device actually responds to VGA accesses or that the PCI ROM
payload includes a VGA BIOS.

Maybe that's how the arbiter device registration should work, if the
class code is VGA add it, if it's 3D controller, switch VGA routing and
see if it responds to VGA.  There are still a couple problems that I've
been beating my head against though.  First, i915 lies when it opts-out
of VGA arbitration, so you might think you've found a VGA device
elsewhere, but you're actually still talking to IGD.  Second is the Xorg
DRI problem where it's going to disable DRI support if suddenly a second
arbitration participant appears.  This is what happened when I tried to
fix the i915 problem and suddenly anybody with IGD + plugin graphics
lost DRI and the fix was reverted.  The whole thing is pretty broken.

In this case, if your laptop actually supports disabling and hiding the
IGD device, I'd expect the Nvidia device to switch to reporting itself
as VGA.  It seems like often the Optimus graphics aren't even directly
connected to an output device, which makes me curious that you can
actually pick one or the other.  Thanks,

Alex

> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson <alex.williamson@redhat.com
> > wrote:
> 
> > On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> > > Adding proper people and mailing lists..
> > >
> > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> > > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> > > appropriate, but hopefully somebody does. The fact that it makes
> > > things work certainly argues fairly convincingly for it, but I want
> > > some backup here.
> > >
> > > Dave, BenH?
> >
> > TBH, it seems pretty dubious to me.  There's nothing in the spec that
> > would give us reason to believe that a device with a 3D controller class
> > code requires VGA arbitration.  Also, if this controller starts
> > participating in arbitration then this same laptop will likely disable
> > DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
> > MMIO space.  I'm not sure what the solution is, but unfortunately it's
> > likely to be much more complicated than this patch.  Thanks,
> >
> > Alex
> >
> > > Christopher(?), can you please also specify which laptop etc. And the
> > > patch itself seems to have come from somebody else, unless you're
> > > Lekensteyn. So we'd want to get the provenance of that too.
> > >
> > >                 Linus
> > >
> > > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
> > wrote:
> > > > Hi Linus,
> > > >
> > > > I don't know who the original author is and I can have one of the
> > distro
> > > > graphics friends review it, but I need this patch below to get NVIDIA
> > > > drivers to work (without using any Intel graphics) on my laptop
> > > > http://pastebin.com/wpmFi38k
> > > >
> > > > Sorry - I know this is not the proper way to submit a patch, but it's
> > > > trivial and I'm not a kernel dev.
> > > >
> > > > Thanks
> > > >
> > > > ./C
> >
> >
> >
> >



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

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Williamson]

On Tue, 2014-09-23 at 04:20 +0700, C Bergström wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
> 
> How is a laptop with dual VGA controllers any different than if one
> identifies itself as a "3D controller"?

With dual VGA controllers, we can change VGA routing in the chipset so
that we can address one device or the other using the VGA address space.
This lets things like Xorg switch between cards to initialize a card via
the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
reports itself as a 3D controller, then we have no reason to believe
that the device actually responds to VGA accesses or that the PCI ROM
payload includes a VGA BIOS.

Maybe that's how the arbiter device registration should work, if the
class code is VGA add it, if it's 3D controller, switch VGA routing and
see if it responds to VGA.  There are still a couple problems that I've
been beating my head against though.  First, i915 lies when it opts-out
of VGA arbitration, so you might think you've found a VGA device
elsewhere, but you're actually still talking to IGD.  Second is the Xorg
DRI problem where it's going to disable DRI support if suddenly a second
arbitration participant appears.  This is what happened when I tried to
fix the i915 problem and suddenly anybody with IGD + plugin graphics
lost DRI and the fix was reverted.  The whole thing is pretty broken.

In this case, if your laptop actually supports disabling and hiding the
IGD device, I'd expect the Nvidia device to switch to reporting itself
as VGA.  It seems like often the Optimus graphics aren't even directly
connected to an output device, which makes me curious that you can
actually pick one or the other.  Thanks,

Alex

> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson <alex.williamson@redhat.com
> > wrote:
> 
> > On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> > > Adding proper people and mailing lists..
> > >
> > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> > > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> > > appropriate, but hopefully somebody does. The fact that it makes
> > > things work certainly argues fairly convincingly for it, but I want
> > > some backup here.
> > >
> > > Dave, BenH?
> >
> > TBH, it seems pretty dubious to me.  There's nothing in the spec that
> > would give us reason to believe that a device with a 3D controller class
> > code requires VGA arbitration.  Also, if this controller starts
> > participating in arbitration then this same laptop will likely disable
> > DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
> > MMIO space.  I'm not sure what the solution is, but unfortunately it's
> > likely to be much more complicated than this patch.  Thanks,
> >
> > Alex
> >
> > > Christopher(?), can you please also specify which laptop etc. And the
> > > patch itself seems to have come from somebody else, unless you're
> > > Lekensteyn. So we'd want to get the provenance of that too.
> > >
> > >                 Linus
> > >
> > > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
> > wrote:
> > > > Hi Linus,
> > > >
> > > > I don't know who the original author is and I can have one of the
> > distro
> > > > graphics friends review it, but I need this patch below to get NVIDIA
> > > > drivers to work (without using any Intel graphics) on my laptop
> > > > http://pastebin.com/wpmFi38k
> > > >
> > > > Sorry - I know this is not the proper way to submit a patch, but it's
> > > > trivial and I'm not a kernel dev.
> > > >
> > > > Thanks
> > > >
> > > > ./C
> >
> >
> >
> >

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Deucher]

On Mon, Sep 22, 2014 at 5:54 PM, Alex Williamson
<alex.williamson@redhat.com> wrote:
> On Tue, 2014-09-23 at 04:20 +0700, C Bergström wrote:
>> For clarity - My testing and the patch is required when the Intel driver
>> isn't being used at all. After I finish some other testing I can see if
>> bumblebee and intel driver + this patch will play nicely.
>>
>> How is a laptop with dual VGA controllers any different than if one
>> identifies itself as a "3D controller"?
>
> With dual VGA controllers, we can change VGA routing in the chipset so
> that we can address one device or the other using the VGA address space.
> This lets things like Xorg switch between cards to initialize a card via
> the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
> reports itself as a 3D controller, then we have no reason to believe
> that the device actually responds to VGA accesses or that the PCI ROM
> payload includes a VGA BIOS.
>
> Maybe that's how the arbiter device registration should work, if the
> class code is VGA add it, if it's 3D controller, switch VGA routing and
> see if it responds to VGA.  There are still a couple problems that I've
> been beating my head against though.  First, i915 lies when it opts-out
> of VGA arbitration, so you might think you've found a VGA device
> elsewhere, but you're actually still talking to IGD.  Second is the Xorg
> DRI problem where it's going to disable DRI support if suddenly a second
> arbitration participant appears.  This is what happened when I tried to
> fix the i915 problem and suddenly anybody with IGD + plugin graphics
> lost DRI and the fix was reverted.  The whole thing is pretty broken.
>
> In this case, if your laptop actually supports disabling and hiding the
> IGD device, I'd expect the Nvidia device to switch to reporting itself
> as VGA.  It seems like often the Optimus graphics aren't even directly
> connected to an output device, which makes me curious that you can
> actually pick one or the other.  Thanks,

AFAIK, on most recent (like in the last 2-3 years) hybrid laptops
don't really have the option to boot to the dGPU or even disable the
integrated graphics (I'm not sure that was ever possibly, even on the
old muxed ones).  Depending on the OEM, the dGPU may be wired to one
or more of the external ports, but I don't think those are usable
until after the drivers have loaded.  Newer radeon PowerXpress laptops
mark the dGPU as PCI_CLASS_DISPLAY_OTHER and I don't think there is
any expectation that they should be messing with vga.

Alex

>
> Alex
>
>> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson <alex.williamson@redhat.com
>> > wrote:
>>
>> > On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> > > Adding proper people and mailing lists..
>> > >
>> > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> > > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> > > appropriate, but hopefully somebody does. The fact that it makes
>> > > things work certainly argues fairly convincingly for it, but I want
>> > > some backup here.
>> > >
>> > > Dave, BenH?
>> >
>> > TBH, it seems pretty dubious to me.  There's nothing in the spec that
>> > would give us reason to believe that a device with a 3D controller class
>> > code requires VGA arbitration.  Also, if this controller starts
>> > participating in arbitration then this same laptop will likely disable
>> > DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
>> > MMIO space.  I'm not sure what the solution is, but unfortunately it's
>> > likely to be much more complicated than this patch.  Thanks,
>> >
>> > Alex
>> >
>> > > Christopher(?), can you please also specify which laptop etc. And the
>> > > patch itself seems to have come from somebody else, unless you're
>> > > Lekensteyn. So we'd want to get the provenance of that too.
>> > >
>> > >                 Linus
>> > >
>> > > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
>> > wrote:
>> > > > Hi Linus,
>> > > >
>> > > > I don't know who the original author is and I can have one of the
>> > distro
>> > > > graphics friends review it, but I need this patch below to get NVIDIA
>> > > > drivers to work (without using any Intel graphics) on my laptop
>> > > > http://pastebin.com/wpmFi38k
>> > > >
>> > > > Sorry - I know this is not the proper way to submit a patch, but it's
>> > > > trivial and I'm not a kernel dev.
>> > > >
>> > > > Thanks
>> > > >
>> > > > ./C
>> >
>> >
>> >
>> >
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Deucher]

On Mon, Sep 22, 2014 at 5:54 PM, Alex Williamson
<alex.williamson@redhat.com> wrote:
> On Tue, 2014-09-23 at 04:20 +0700, C Bergström wrote:
>> For clarity - My testing and the patch is required when the Intel driver
>> isn't being used at all. After I finish some other testing I can see if
>> bumblebee and intel driver + this patch will play nicely.
>>
>> How is a laptop with dual VGA controllers any different than if one
>> identifies itself as a "3D controller"?
>
> With dual VGA controllers, we can change VGA routing in the chipset so
> that we can address one device or the other using the VGA address space.
> This lets things like Xorg switch between cards to initialize a card via
> the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
> reports itself as a 3D controller, then we have no reason to believe
> that the device actually responds to VGA accesses or that the PCI ROM
> payload includes a VGA BIOS.
>
> Maybe that's how the arbiter device registration should work, if the
> class code is VGA add it, if it's 3D controller, switch VGA routing and
> see if it responds to VGA.  There are still a couple problems that I've
> been beating my head against though.  First, i915 lies when it opts-out
> of VGA arbitration, so you might think you've found a VGA device
> elsewhere, but you're actually still talking to IGD.  Second is the Xorg
> DRI problem where it's going to disable DRI support if suddenly a second
> arbitration participant appears.  This is what happened when I tried to
> fix the i915 problem and suddenly anybody with IGD + plugin graphics
> lost DRI and the fix was reverted.  The whole thing is pretty broken.
>
> In this case, if your laptop actually supports disabling and hiding the
> IGD device, I'd expect the Nvidia device to switch to reporting itself
> as VGA.  It seems like often the Optimus graphics aren't even directly
> connected to an output device, which makes me curious that you can
> actually pick one or the other.  Thanks,

AFAIK, on most recent (like in the last 2-3 years) hybrid laptops
don't really have the option to boot to the dGPU or even disable the
integrated graphics (I'm not sure that was ever possibly, even on the
old muxed ones).  Depending on the OEM, the dGPU may be wired to one
or more of the external ports, but I don't think those are usable
until after the drivers have loaded.  Newer radeon PowerXpress laptops
mark the dGPU as PCI_CLASS_DISPLAY_OTHER and I don't think there is
any expectation that they should be messing with vga.

Alex

>
> Alex
>
>> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson <alex.williamson@redhat.com
>> > wrote:
>>
>> > On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> > > Adding proper people and mailing lists..
>> > >
>> > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> > > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> > > appropriate, but hopefully somebody does. The fact that it makes
>> > > things work certainly argues fairly convincingly for it, but I want
>> > > some backup here.
>> > >
>> > > Dave, BenH?
>> >
>> > TBH, it seems pretty dubious to me.  There's nothing in the spec that
>> > would give us reason to believe that a device with a 3D controller class
>> > code requires VGA arbitration.  Also, if this controller starts
>> > participating in arbitration then this same laptop will likely disable
>> > DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
>> > MMIO space.  I'm not sure what the solution is, but unfortunately it's
>> > likely to be much more complicated than this patch.  Thanks,
>> >
>> > Alex
>> >
>> > > Christopher(?), can you please also specify which laptop etc. And the
>> > > patch itself seems to have come from somebody else, unless you're
>> > > Lekensteyn. So we'd want to get the provenance of that too.
>> > >
>> > >                 Linus
>> > >
>> > > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
>> > wrote:
>> > > > Hi Linus,
>> > > >
>> > > > I don't know who the original author is and I can have one of the
>> > distro
>> > > > graphics friends review it, but I need this patch below to get NVIDIA
>> > > > drivers to work (without using any Intel graphics) on my laptop
>> > > > http://pastebin.com/wpmFi38k
>> > > >
>> > > > Sorry - I know this is not the proper way to submit a patch, but it's
>> > > > trivial and I'm not a kernel dev.
>> > > >
>> > > > Thanks
>> > > >
>> > > > ./C
>> >
>> >
>> >
>> >
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stupid NVIDIA 3D vgaarb.c patch

[Pasi Kärkkäinen]

On Mon, Sep 22, 2014 at 06:10:50PM -0400, Alex Deucher wrote:
> >
> > With dual VGA controllers, we can change VGA routing in the chipset so
> > that we can address one device or the other using the VGA address space.
> > This lets things like Xorg switch between cards to initialize a card via
> > the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
> > reports itself as a 3D controller, then we have no reason to believe
> > that the device actually responds to VGA accesses or that the PCI ROM
> > payload includes a VGA BIOS.
> >
> > Maybe that's how the arbiter device registration should work, if the
> > class code is VGA add it, if it's 3D controller, switch VGA routing and
> > see if it responds to VGA.  There are still a couple problems that I've
> > been beating my head against though.  First, i915 lies when it opts-out
> > of VGA arbitration, so you might think you've found a VGA device
> > elsewhere, but you're actually still talking to IGD.  Second is the Xorg
> > DRI problem where it's going to disable DRI support if suddenly a second
> > arbitration participant appears.  This is what happened when I tried to
> > fix the i915 problem and suddenly anybody with IGD + plugin graphics
> > lost DRI and the fix was reverted.  The whole thing is pretty broken.
> >
> > In this case, if your laptop actually supports disabling and hiding the
> > IGD device, I'd expect the Nvidia device to switch to reporting itself
> > as VGA.  It seems like often the Optimus graphics aren't even directly
> > connected to an output device, which makes me curious that you can
> > actually pick one or the other.  Thanks,
> 
> AFAIK, on most recent (like in the last 2-3 years) hybrid laptops
> don't really have the option to boot to the dGPU or even disable the
> integrated graphics (I'm not sure that was ever possibly, even on the
> old muxed ones).  Depending on the OEM, the dGPU may be wired to one
> or more of the external ports, but I don't think those are usable
> until after the drivers have loaded.  Newer radeon PowerXpress laptops
> mark the dGPU as PCI_CLASS_DISPLAY_OTHER and I don't think there is
> any expectation that they should be messing with vga.
>

I had Lenovo T430 hybrid graphics laptop earlier, which is in "last 2-3 years",
and it allowed me to choose "IGD only", "Optimus", or "Nvidia only" in BIOS..


-- Pasi
 
> Alex
> 

Re: Stupid NVIDIA 3D vgaarb.c patch

[Pasi Kärkkäinen]

On Mon, Sep 22, 2014 at 06:10:50PM -0400, Alex Deucher wrote:
> >
> > With dual VGA controllers, we can change VGA routing in the chipset so
> > that we can address one device or the other using the VGA address space.
> > This lets things like Xorg switch between cards to initialize a card via
> > the VGA BIOS or execute runtime VGA BIOS calls.  If one of those devices
> > reports itself as a 3D controller, then we have no reason to believe
> > that the device actually responds to VGA accesses or that the PCI ROM
> > payload includes a VGA BIOS.
> >
> > Maybe that's how the arbiter device registration should work, if the
> > class code is VGA add it, if it's 3D controller, switch VGA routing and
> > see if it responds to VGA.  There are still a couple problems that I've
> > been beating my head against though.  First, i915 lies when it opts-out
> > of VGA arbitration, so you might think you've found a VGA device
> > elsewhere, but you're actually still talking to IGD.  Second is the Xorg
> > DRI problem where it's going to disable DRI support if suddenly a second
> > arbitration participant appears.  This is what happened when I tried to
> > fix the i915 problem and suddenly anybody with IGD + plugin graphics
> > lost DRI and the fix was reverted.  The whole thing is pretty broken.
> >
> > In this case, if your laptop actually supports disabling and hiding the
> > IGD device, I'd expect the Nvidia device to switch to reporting itself
> > as VGA.  It seems like often the Optimus graphics aren't even directly
> > connected to an output device, which makes me curious that you can
> > actually pick one or the other.  Thanks,
> 
> AFAIK, on most recent (like in the last 2-3 years) hybrid laptops
> don't really have the option to boot to the dGPU or even disable the
> integrated graphics (I'm not sure that was ever possibly, even on the
> old muxed ones).  Depending on the OEM, the dGPU may be wired to one
> or more of the external ports, but I don't think those are usable
> until after the drivers have loaded.  Newer radeon PowerXpress laptops
> mark the dGPU as PCI_CLASS_DISPLAY_OTHER and I don't think there is
> any expectation that they should be messing with vga.
>

I had Lenovo T430 hybrid graphics laptop earlier, which is in "last 2-3 years",
and it allowed me to choose "IGD only", "Optimus", or "Nvidia only" in BIOS..


-- Pasi
 
> Alex
> 

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Deucher]

On Mon, Sep 22, 2014 at 5:20 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
>
> How is a laptop with dual VGA controllers any different than if one
> identifies itself as a "3D controller"?
>

I'm not familiar with nvidia hw, but some newer AMD asics don't have
any vga hw at all so they would have no need to have vga routed to
them ever.

Alex

> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> > Adding proper people and mailing lists..
>> >
>> > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> > appropriate, but hopefully somebody does. The fact that it makes
>> > things work certainly argues fairly convincingly for it, but I want
>> > some backup here.
>> >
>> > Dave, BenH?
>>
>> TBH, it seems pretty dubious to me.  There's nothing in the spec that
>> would give us reason to believe that a device with a 3D controller class
>> code requires VGA arbitration.  Also, if this controller starts
>> participating in arbitration then this same laptop will likely disable
>> DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
>> MMIO space.  I'm not sure what the solution is, but unfortunately it's
>> likely to be much more complicated than this patch.  Thanks,
>>
>> Alex
>>
>> > Christopher(?), can you please also specify which laptop etc. And the
>> > patch itself seems to have come from somebody else, unless you're
>> > Lekensteyn. So we'd want to get the provenance of that too.
>> >
>> >                 Linus
>> >
>> > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
>> > wrote:
>> > > Hi Linus,
>> > >
>> > > I don't know who the original author is and I can have one of the
>> > > distro
>> > > graphics friends review it, but I need this patch below to get NVIDIA
>> > > drivers to work (without using any Intel graphics) on my laptop
>> > > http://pastebin.com/wpmFi38k
>> > >
>> > > Sorry - I know this is not the proper way to submit a patch, but it's
>> > > trivial and I'm not a kernel dev.
>> > >
>> > > Thanks
>> > >
>> > > ./C
>>
>>
>>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stupid NVIDIA 3D vgaarb.c patch

[Alex Deucher]

On Mon, Sep 22, 2014 at 5:20 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
>
> How is a laptop with dual VGA controllers any different than if one
> identifies itself as a "3D controller"?
>

I'm not familiar with nvidia hw, but some newer AMD asics don't have
any vga hw at all so they would have no need to have vga routed to
them ever.

Alex

> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> > Adding proper people and mailing lists..
>> >
>> > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> > appropriate, but hopefully somebody does. The fact that it makes
>> > things work certainly argues fairly convincingly for it, but I want
>> > some backup here.
>> >
>> > Dave, BenH?
>>
>> TBH, it seems pretty dubious to me.  There's nothing in the spec that
>> would give us reason to believe that a device with a 3D controller class
>> code requires VGA arbitration.  Also, if this controller starts
>> participating in arbitration then this same laptop will likely disable
>> DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
>> MMIO space.  I'm not sure what the solution is, but unfortunately it's
>> likely to be much more complicated than this patch.  Thanks,
>>
>> Alex
>>
>> > Christopher(?), can you please also specify which laptop etc. And the
>> > patch itself seems to have come from somebody else, unless you're
>> > Lekensteyn. So we'd want to get the provenance of that too.
>> >
>> >                 Linus
>> >
>> > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com>
>> > wrote:
>> > > Hi Linus,
>> > >
>> > > I don't know who the original author is and I can have one of the
>> > > distro
>> > > graphics friends review it, but I need this patch below to get NVIDIA
>> > > drivers to work (without using any Intel graphics) on my laptop
>> > > http://pastebin.com/wpmFi38k
>> > >
>> > > Sorry - I know this is not the proper way to submit a patch, but it's
>> > > trivial and I'm not a kernel dev.
>> > >
>> > > Thanks
>> > >
>> > > ./C
>>
>>
>>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: Stupid NVIDIA 3D vgaarb.c patch

[Bruno Prémont]

On Mon, 22 September 2014 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Adding proper people and mailing lists..
> 
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> things work certainly argues fairly convincingly for it, but I want
> some backup here.
> 
> Dave, BenH?
> 
> Christopher(?), can you please also specify which laptop etc. And the
> patch itself seems to have come from somebody else, unless you're
> Lekensteyn. So we'd want to get the provenance of that too.

More a question to Christopher, but what criteria is preventing the use
of the NVIDIA GPU under this condition?

As far as I've seen on my (single-GPU) systems X requires the GPU to
have boot_vga=1 sysfs attribute to accept autoconfiguration (though
with two GPUs and optimus/switcheroo interaction between the GPUs may
change the picture).

I've been looking at the open, nouveau side of things only. If NVIDIA
closed driver has some other requirement, I don't know.

But as here the intention seems to be to use exclusively the NVIDIA GPU
just leaving the IGD along it should require explicit X configuration
which then does not care about boot_vga.


A more detailed description of what prevents operation with GPU not
being added to vgaarb would certainly help understanding what happens,
what is expected and where things differ.

Bruno

>                 Linus
> 
> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> > Hi Linus,
> >
> > I don't know who the original author is and I can have one of the distro
> > graphics friends review it, but I need this patch below to get NVIDIA
> > drivers to work (without using any Intel graphics) on my laptop
> > http://pastebin.com/wpmFi38k
> >
> > Sorry - I know this is not the proper way to submit a patch, but it's
> > trivial and I'm not a kernel dev.
> >
> > Thanks
> >
> > ./C
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stupid NVIDIA 3D vgaarb.c patch

[Bruno Prémont]

On Mon, 22 September 2014 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Adding proper people and mailing lists..
> 
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> things work certainly argues fairly convincingly for it, but I want
> some backup here.
> 
> Dave, BenH?
> 
> Christopher(?), can you please also specify which laptop etc. And the
> patch itself seems to have come from somebody else, unless you're
> Lekensteyn. So we'd want to get the provenance of that too.

More a question to Christopher, but what criteria is preventing the use
of the NVIDIA GPU under this condition?

As far as I've seen on my (single-GPU) systems X requires the GPU to
have boot_vga=1 sysfs attribute to accept autoconfiguration (though
with two GPUs and optimus/switcheroo interaction between the GPUs may
change the picture).

I've been looking at the open, nouveau side of things only. If NVIDIA
closed driver has some other requirement, I don't know.

But as here the intention seems to be to use exclusively the NVIDIA GPU
just leaving the IGD along it should require explicit X configuration
which then does not care about boot_vga.


A more detailed description of what prevents operation with GPU not
being added to vgaarb would certainly help understanding what happens,
what is expected and where things differ.

Bruno

>                 Linus
> 
> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> > Hi Linus,
> >
> > I don't know who the original author is and I can have one of the distro
> > graphics friends review it, but I need this patch below to get NVIDIA
> > drivers to work (without using any Intel graphics) on my laptop
> > http://pastebin.com/wpmFi38k
> >
> > Sorry - I know this is not the proper way to submit a patch, but it's
> > trivial and I'm not a kernel dev.
> >
> > Thanks
> >
> > ./C

Re: Stupid NVIDIA 3D vgaarb.c patch

[Benjamin Herrenschmidt]

On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> Adding proper people and mailing lists..
> 
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> things work certainly argues fairly convincingly for it, but I want
> some backup here.
> 
> Dave, BenH?
> 
> Christopher(?), can you please also specify which laptop etc. And the
> patch itself seems to have come from somebody else, unless you're
> Lekensteyn. So we'd want to get the provenance of that too.

Hrm, that sucks. "3D" could mean anything really, we might need an
explicit vendor ID check as well and maybe even device ID ...

Ben.

>                 Linus
> 
> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
> > Hi Linus,
> >
> > I don't know who the original author is and I can have one of the distro
> > graphics friends review it, but I need this patch below to get NVIDIA
> > drivers to work (without using any Intel graphics) on my laptop
> > http://pastebin.com/wpmFi38k
> >
> > Sorry - I know this is not the proper way to submit a patch, but it's
> > trivial and I'm not a kernel dev.
> >
> > Thanks
> >
> > ./C

Re: Stupid NVIDIA 3D vgaarb.c patch

[Aaron Plattner]

On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> Adding proper people and mailing lists..
>>
>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> appropriate, but hopefully somebody does. The fact that it makes
>> things work certainly argues fairly convincingly for it, but I want
>> some backup here.
>>
>> Dave, BenH?
>>
>> Christopher(?), can you please also specify which laptop etc. And the
>> patch itself seems to have come from somebody else, unless you're
>> Lekensteyn. So we'd want to get the provenance of that too.
>
> Hrm, that sucks. "3D" could mean anything really, we might need an
> explicit vendor ID check as well and maybe even device ID ...

If my understanding is correct, the board designers explicitly mark them 
as "3D controller" when they don't have any outputs connected, 
specifically so the SBIOS won't choose them as the boot VGA device. 
Depending on the design, some GPUs on these 3D controller boards don't 
have a display engine at all, while others still have it in the silicon 
but leave it disabled at runtime.  In either case, VGA should not be 
routed to them and I don't think they should need to participate in VGA 
arbitration.

-- Aaron

> Ben.
>
>>                  Linus
>>
>> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
>>> Hi Linus,
>>>
>>> I don't know who the original author is and I can have one of the distro
>>> graphics friends review it, but I need this patch below to get NVIDIA
>>> drivers to work (without using any Intel graphics) on my laptop
>>> http://pastebin.com/wpmFi38k
>>>
>>> Sorry - I know this is not the proper way to submit a patch, but it's
>>> trivial and I'm not a kernel dev.
>>>
>>> Thanks
>>>
>>> ./C
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Stupid NVIDIA 3D vgaarb.c patch

[Aaron Plattner]

On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> Adding proper people and mailing lists..
>>
>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> appropriate, but hopefully somebody does. The fact that it makes
>> things work certainly argues fairly convincingly for it, but I want
>> some backup here.
>>
>> Dave, BenH?
>>
>> Christopher(?), can you please also specify which laptop etc. And the
>> patch itself seems to have come from somebody else, unless you're
>> Lekensteyn. So we'd want to get the provenance of that too.
>
> Hrm, that sucks. "3D" could mean anything really, we might need an
> explicit vendor ID check as well and maybe even device ID ...

If my understanding is correct, the board designers explicitly mark them 
as "3D controller" when they don't have any outputs connected, 
specifically so the SBIOS won't choose them as the boot VGA device. 
Depending on the design, some GPUs on these 3D controller boards don't 
have a display engine at all, while others still have it in the silicon 
but leave it disabled at runtime.  In either case, VGA should not be 
routed to them and I don't think they should need to participate in VGA 
arbitration.

-- Aaron

> Ben.
>
>>                  Linus
>>
>> On Mon, Sep 22, 2014 at 1:28 PM, C Bergström <cbergstrom@pathscale.com> wrote:
>>> Hi Linus,
>>>
>>> I don't know who the original author is and I can have one of the distro
>>> graphics friends review it, but I need this patch below to get NVIDIA
>>> drivers to work (without using any Intel graphics) on my laptop
>>> http://pastebin.com/wpmFi38k
>>>
>>> Sorry - I know this is not the proper way to submit a patch, but it's
>>> trivial and I'm not a kernel dev.
>>>
>>> Thanks
>>>
>>> ./C

Re: Stupid NVIDIA 3D vgaarb.c patch

[Ilia Mirkin]

On Fri, Sep 26, 2014 at 5:08 PM, Aaron Plattner <aplattner@nvidia.com> wrote:
> On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>>>
>>> Adding proper people and mailing lists..
>>>
>>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>>> appropriate, but hopefully somebody does. The fact that it makes
>>> things work certainly argues fairly convincingly for it, but I want
>>> some backup here.
>>>
>>> Dave, BenH?
>>>
>>> Christopher(?), can you please also specify which laptop etc. And the
>>> patch itself seems to have come from somebody else, unless you're
>>> Lekensteyn. So we'd want to get the provenance of that too.
>>
>>
>> Hrm, that sucks. "3D" could mean anything really, we might need an
>> explicit vendor ID check as well and maybe even device ID ...
>
>
> If my understanding is correct, the board designers explicitly mark them as
> "3D controller" when they don't have any outputs connected, specifically so
> the SBIOS won't choose them as the boot VGA device. Depending on the design,
> some GPUs on these 3D controller boards don't have a display engine at all,
> while others still have it in the silicon but leave it disabled at runtime.
> In either case, VGA should not be routed to them and I don't think they
> should need to participate in VGA arbitration.

Without commenting on the vga aspects of this discussion (about which
I know next to nothing), I'm moderately sure the nouveau team has seen
optimus setups where the secondary GPU reports itself as a 3d
controller, but has a working display engine, and outputs connected to
it. And I believe the inverse has also happened (a device that reports
itself as VGA but has no outputs advertised and a potentially-absent
display engine).

  -ilia

Re: Stupid NVIDIA 3D vgaarb.c patch

[Ilia Mirkin]

On Fri, Sep 26, 2014 at 5:08 PM, Aaron Plattner <aplattner@nvidia.com> wrote:
> On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>>>
>>> Adding proper people and mailing lists..
>>>
>>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>>> appropriate, but hopefully somebody does. The fact that it makes
>>> things work certainly argues fairly convincingly for it, but I want
>>> some backup here.
>>>
>>> Dave, BenH?
>>>
>>> Christopher(?), can you please also specify which laptop etc. And the
>>> patch itself seems to have come from somebody else, unless you're
>>> Lekensteyn. So we'd want to get the provenance of that too.
>>
>>
>> Hrm, that sucks. "3D" could mean anything really, we might need an
>> explicit vendor ID check as well and maybe even device ID ...
>
>
> If my understanding is correct, the board designers explicitly mark them as
> "3D controller" when they don't have any outputs connected, specifically so
> the SBIOS won't choose them as the boot VGA device. Depending on the design,
> some GPUs on these 3D controller boards don't have a display engine at all,
> while others still have it in the silicon but leave it disabled at runtime.
> In either case, VGA should not be routed to them and I don't think they
> should need to participate in VGA arbitration.

Without commenting on the vga aspects of this discussion (about which
I know next to nothing), I'm moderately sure the nouveau team has seen
optimus setups where the secondary GPU reports itself as a 3d
controller, but has a working display engine, and outputs connected to
it. And I believe the inverse has also happened (a device that reports
itself as VGA but has no outputs advertised and a potentially-absent
display engine).

  -ilia