Bug 109298 - AMDGPU leaving DRI2 enabled causes white artifacting
Summary: AMDGPU leaving DRI2 enabled causes white artifacting
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-11 03:04 UTC by tkdestroyer2+bugs-freedesktop
Modified: 2019-11-19 09:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Screenshot (15.75 KB, image/png)
2019-01-11 19:23 UTC, tkdestroyer2+bugs-freedesktop
no flags Details
dmesg log (75.04 KB, text/plain)
2019-01-11 19:24 UTC, tkdestroyer2+bugs-freedesktop
no flags Details
xorg log (60.55 KB, text/plain)
2019-01-11 19:25 UTC, tkdestroyer2+bugs-freedesktop
no flags Details

Description tkdestroyer2+bugs-freedesktop 2019-01-11 03:04:47 UTC
I am running:
Solus OS
Linux kernel 4.18.5
xorg-driver-video-amdgpu 18.1.0
xinit 1.4.0
xorg-server 1.20.3
VG248QE DisplayPort 1080@144

$ cat /sys/class/drm/card1/device/vbios_version
MS-V30823-F5

I have an MSI R9 390, one of the bugged ones. I can boot successfully using cik_support=1 dpm=1 and dc=1.

The bug I am encountering is the following:

- Use default Xorg configuration
- Encounter white rectangles where there should be rendered content
  ex: Desktop background is between 6 and 9 tenths white starting from the top going down. Only the rest of the bottom strip is showing.
  ex: Firefox shows white rectangles of white pixels where there should be content. They vary in size and position and tend to show up after recent renderings. Can be 'wiped' away using the mouse-highlight.

I have managed to reduce the impact of this bug by switching off DRI2 by setting xorg configuration option AccelMethod to none. No other configuration of options (as they appear in the manpages for amdgpu) will work in removing these issues. This lets me utilize accelerated 3D graphics until I can get DRI2 up and running again.

It may be important to note that some applications will work, particularly when they are small windows, like when first opening a PDF. Scrolling and everything works normally, but when one maximizes the window to 1080p, the artifacts appear. One application that worked is MineTest, which appears to be using 2D rendering (poor performance with DRI2 off).
Comment 1 Michel Dänzer 2019-01-11 14:07:15 UTC
(In reply to tkdestroyer2+bugs-freedesktop from comment #0)
> I have an MSI R9 390, one of the bugged ones. I can boot successfully using
> cik_support=1 dpm=1 and dc=1.

Does not specifying the dpm parameter at all on the kernel command line or anywhere else make a difference?


Please attach a screenshot, the Xorg log file and the output of dmesg corresponding to the problem.
Comment 2 tkdestroyer2+bugs-freedesktop 2019-01-11 19:21:50 UTC
(In reply to Michel Dänzer from comment #1)
> Does not specifying the dpm parameter at all on the kernel command line or
> anywhere else make a difference?

I just tested. DPM is required to prevent crashing, but DC is not.
Comment 3 tkdestroyer2+bugs-freedesktop 2019-01-11 19:23:57 UTC
Created attachment 143071 [details]
Screenshot

> Please attach a screenshot, the Xorg log file and the output of dmesg
> corresponding to the problem.

The screenshot was not able to capture a majority of the screen (shown in black) for some reason. The point can still be seen in the bottom, in a screenshot of the freedesktop bug list.
Comment 4 tkdestroyer2+bugs-freedesktop 2019-01-11 19:24:59 UTC
Created attachment 143072 [details]
dmesg log
Comment 5 tkdestroyer2+bugs-freedesktop 2019-01-11 19:25:20 UTC
Created attachment 143073 [details]
xorg log
Comment 6 Alex Deucher 2019-01-11 20:46:28 UTC
(In reply to tkdestroyer2+bugs-freedesktop from comment #2)
> (In reply to Michel Dänzer from comment #1)
> > Does not specifying the dpm parameter at all on the kernel command line or
> > anywhere else make a difference?
> 
> I just tested. DPM is required to prevent crashing, but DC is not.

4.18 and older used the old dpm implementation by default and setting to 1 selected the new one.  The new on is default in 4.19, so you no longer need to specify dpm=1 as of 4.19.
Comment 7 Martin Peres 2019-11-19 09:10:18 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/666.


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.