So far I met the same PCI ID 1002:15d8 with 2GB VRAM which was working fine in prime output mode with any nvidia gpu as provider. The mentioned version with 128MB VRAM doesn't work. No error messages regarding prime, just the screen staying black. https://devtalk.nvidia.com/default/topic/1056652/linux/amd-ryzen-7-geforce-gtx-1660-ti-laptop-gt-cannot-get-nvidia-to-be-used-as-primary-graphics/1
Created attachment 144876 [details] nvidia bug report I'm consistentky trying to run my Nvidia gtx 1660 Ti on laptop with Ryzen 7 processor. So far unsucessfull trying to get into GUI. It might be something related to iommu and power management when trying to open and close the laptop lid. Laptop model Ausus TUF 505 DU. Any help will be appreciated.
https://devtalk.nvidia.com/default/topic/1056652/linux/amd-ryzen-7-geforce-gtx-1660-ti-laptop-gt-cannot-get-nvidia-to-be-used-as-primary-graphics/post/5365696/#5365696
From the attached bug report log: *** /usr/share/X11/xorg.conf.d/10-amdgpu.conf *** ls: -rw-r--r-- 1 root root 98 2019-07-12 20:45:36.635624123 +1000 /usr/share/X11/xorg.conf.d/10-amdgpu.conf Section "OutputClass" Identifier "AMDgpu" MatchDriver "amdgpu" Driver "modesetting" EndSection This file originally says Driver "amdgpu" not "modesetting". Who/what modified this file? Does the problem also occur with the unmodified file, so that the Xorg amdgpu driver is used?
Both amdgpu and modesetting driver were tested, same effect. Most notewothy in the non-prime modesetting driver case is this: [ 5.477] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x1002 / 0x15d8 [ 5.477] (EE) modeset(0): Failed to initialize the DRI2 extension. [ 5.477] (--) RandR disabled [ 5.480] (II) SELinux: Disabled on system [ 5.480] (II) AIGLX: Screen 0 is not DRI2 capable [ 5.480] (EE) AIGLX: reverting to software rendering On those other systems mentioned with 2GB VRAM, the modesetting driver runs fine in any case. This seems to be a different bug with the modesetting driver, though. Non-prime+amdgpu driver runs fine. Since the display starts to work after a suspend/resume cycle, seems to be a kernel bug?
Created attachment 144955 [details] nvidia bug report Ubuntu
Similar situation --> if not exactly the same. Except I don't need to do any nvidia-blacklist as a backup. Nvidia is just blacklisted itself. Also strange power management when You pres the switch off button most often the system doesn't shutdown. Need to press the power button manually to make it happen.
Updating with info from other users with the same amd gpu with 128MB VRAM: - one user was able to switch to VT and start a second Xserver which then worked fine. - another user found out that connecting an external monitor would work, was able to log into gnome and in the monitor manager, the internal display showed as disabled. So he could simply enable it and started working. So this seems to be failing on xrandr --auto, not correctly adding the internal display to the config. Looking what Ubuntu does: # Pass provider or sink and source xrandr --setprovideroutputsource "$sink" "$src" # Make sure xrandr sees all the outputs xrandr --auto # Do not move up. Only now xrandr shows the outputs lvds=$(xrandr | grep -i -e "lvds" -e "edp" | head -n1 |cut -d " " -f 1) xrandr --output "$lvds" --off xrandr --output "$lvds" --auto So it already disables and enables the internal display as a workaround for something but this still isn't enough in this case. Maybe this is some timing problem so that adding a "sleep 2" either before or after xrandr --auto would make that work? Doesn't explain why this is only happening on this specific model, though.
A note on amdgpu the amount of VRAM amdgpu is reporting: This is the amount of system memory dedicated to the iGPU. Strange enough, this doesn't seem to be bios configurable, which would be an easy workaround. It seems to be hardcoded, some machines set to 128 MB, others to 2GB.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/877.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.