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
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.
LinusOn 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
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
LinusOn 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
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.
LinusOn 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
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.
LinusOn 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
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.
LinusOn 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
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.
LinusOn 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
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
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.
LinusOn 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
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
LinusOn 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
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.
LinusOn 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
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.
LinusOn 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
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
dri-devel@lists.freedesktop.org
-
Aaron Plattner -
Alex Deucher -
Alex Williamson -
Benjamin Herrenschmidt -
Bruno Prémont -
C Bergström -
Ilia Mirkin -
Linus Torvalds -
Pasi Kärkkäinen -
Peter Wu