Bug 111228

Summary: PRIME output screen stays black on 1002:15d8 with 128MB VRAM
Product: DRI Reporter: Maik Freudenberg <hhfeuer>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
nvidia bug report
none
nvidia bug report Ubuntu none

Description Maik Freudenberg 2019-07-27 01:43:39 UTC
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
Comment 1 djczaps 2019-07-27 02:36:08 UTC
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.
Comment 3 Michel Dänzer 2019-07-29 09:15:22 UTC
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?
Comment 4 Maik Freudenberg 2019-07-29 09:26:38 UTC
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?
Comment 5 djczaps 2019-08-06 10:42:32 UTC
Created attachment 144955 [details]
nvidia bug report Ubuntu
Comment 6 djczaps 2019-08-06 10:45:25 UTC
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.
Comment 7 Maik Freudenberg 2019-10-02 07:44:19 UTC
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.
Comment 8 Maik Freudenberg 2019-10-02 08:08:14 UTC
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.
Comment 9 Martin Peres 2019-11-19 09:37:04 UTC
-- 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.