Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #229350 > unrolled thread

AMD GPU Sea Islands Problem

Back to article view | Back to linux.debian.user

Contents

  AMD GPU Sea Islands Problem Guyenne Tsui <guyenne@gmail.com> - 2020-12-05 15:30 +0100
    Replying. [was Re: AMD GPU Sea Islands Problem] Charles Curley <charlescurley@charlescurley.com> - 2020-12-05 18:10 +0100
      Re: Replying. [was Re: AMD GPU Sea Islands Problem] Kenneth Parker <sea7kenp@gmail.com> - 2020-12-05 18:30 +0100
        Re: Replying. [was Re: AMD GPU Sea Islands Problem] Tixy <tixy@yxit.co.uk> - 2020-12-05 19:30 +0100
        Re: Replying. [was Re: AMD GPU Sea Islands Problem] Charles Curley <charlescurley@charlescurley.com> - 2020-12-05 20:00 +0100
        Re: Replying. [was Re: AMD GPU Sea Islands Problem] Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-05 22:10 +0100
          Re: Replying. [was Re: AMD GPU Sea Islands Problem] rhkramer@gmail.com - 2020-12-05 23:50 +0100
          Re: Replying. [was Re: AMD GPU Sea Islands Problem] Brad Rogers <brad@fineby.me.uk> - 2020-12-06 08:00 +0100
            Re: Replying Teemu Likonen <tlikonen@iki.fi> - 2020-12-06 10:20 +0100
              Re: Replying Brad Rogers <brad@fineby.me.uk> - 2020-12-06 12:30 +0100
                Re: Replying rhkramer@gmail.com - 2020-12-06 13:10 +0100
                  Re: Replying Brad Rogers <brad@fineby.me.uk> - 2020-12-06 13:20 +0100
                Re: Replying Teemu Likonen <tlikonen@iki.fi> - 2020-12-06 14:50 +0100
                  Re: Replying Brad Rogers <brad@fineby.me.uk> - 2020-12-06 15:40 +0100
                    Re: Replying Stefan Monnier <monnier@iro.umontreal.ca> - 2020-12-06 16:00 +0100
                      Re: Replying Brad Rogers <brad@fineby.me.uk> - 2020-12-06 20:00 +0100
                        Re: Replying Teemu Likonen <tlikonen@iki.fi> - 2020-12-06 21:50 +0100
              Re: Replying Paul Johnson <baloo@ursamundi.org> - 2020-12-07 15:50 +0100
          Re: Replying. [was Re: AMD GPU Sea Islands Problem] Celejar <celejar@gmail.com> - 2020-12-08 21:20 +0100
            Re: Replying. [was Re: AMD GPU Sea Islands Problem] Charles Curley <charlescurley@charlescurley.com> - 2020-12-09 01:30 +0100
              Re: Replying. [was Re: AMD GPU Sea Islands Problem] Celejar <celejar@gmail.com> - 2020-12-09 01:50 +0100
                Re: Replying. [was Re: AMD GPU Sea Islands Problem] Charles Curley <charlescurley@charlescurley.com> - 2020-12-09 02:00 +0100
                  Re: Replying. [was Re: AMD GPU Sea Islands Problem] Celejar <celejar@gmail.com> - 2020-12-09 02:40 +0100
                    Re: Replying. [was Re: AMD GPU Sea Islands Problem] Brad Rogers <brad@fineby.me.uk> - 2020-12-09 09:20 +0100
                      Re: Replying. [was Re: AMD GPU Sea Islands Problem] Celejar <celejar@gmail.com> - 2020-12-09 19:20 +0100
      Re: Replying. [was Re: AMD GPU Sea Islands Problem] Guyenne Tsui <guyenne@gmail.com> - 2020-12-11 21:20 +0100
        Re: Replying. [was Re: AMD GPU Sea Islands Problem] Charles Curley <charlescurley@charlescurley.com> - 2020-12-11 22:10 +0100
    Re: AMD GPU Sea Islands Problem Felix Miata <mrmazda@earthlink.net> - 2020-12-05 22:30 +0100
      Re: AMD GPU Sea Islands Problem Guyenne Tsui <guyenne@gmail.com> - 2020-12-06 23:20 +0100
        Re: AMD GPU Sea Islands Problem Felix Miata <mrmazda@earthlink.net> - 2020-12-11 23:20 +0100
          Re: AMD GPU Sea Islands Problem Guyenne Tsui <guyenne@gmail.com> - 2020-12-12 17:30 +0100
            Re: AMD GPU Sea Islands Problem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-12 20:00 +0100
              Re: AMD GPU Sea Islands Problem Guyenne Tsui <guyenne@gmail.com> - 2020-12-26 21:40 +0100
                Re: AMD GPU Sea Islands Problem Felix Miata <mrmazda@earthlink.net> - 2020-12-26 22:00 +0100
                  Re: AMD GPU Sea Islands Problem Guyenne Tsui <guyenne@gmail.com> - 2020-12-26 22:40 +0100
                    Re: AMD GPU Sea Islands Problem Felix Miata <mrmazda@earthlink.net> - 2020-12-26 22:50 +0100
                      Re: AMD GPU Sea Islands Problem Stefan Monnier <monnier@iro.umontreal.ca> - 2020-12-26 23:30 +0100
            Re: AMD GPU Sea Islands Problem "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-12 20:40 +0100
              Re: AMD GPU Sea Islands Problem Guyenne Tsui <guyenne@gmail.com> - 2020-12-26 21:50 +0100
            Re: AMD GPU Sea Islands Problem Felix Miata <mrmazda@earthlink.net> - 2020-12-13 00:50 +0100
        Re: AMD GPU ^H^H^HSea Southern Islands Problem Felix Miata <mrmazda@earthlink.net> - 2020-12-13 01:00 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#229504 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

On Tue, 8 Dec 2020 17:29:22 -0700
Charles Curley <charlescurley@charlescurley.com> wrote:

> On Tue, 8 Dec 2020 15:10:13 -0500
> Celejar <celejar@gmail.com> wrote:
> 
> > On my Sylpheed, ordinary 'Reply' won't do reply-to-list, and I have to
> > specifically ask for that (<CTRL>-L by default). I couldn't find a
> > configuration option to change that, but I might have missed
> > something.
> 
> In Claws-Mail, you can do it on a per-folder basis. Get the address
> to which you wish to reply into the clipboard. Select the folder, and
> right click on it. Select Properties, then Compose. Check and fill out
> "Default to:" and "Default To: Replies". This, of course, over-rides any
> "Reply-To:" header.
> 
> That assumes you have a folder for each mailing list. If you don't,
> they are easy enough to set up.

Ah, yes. Those are Sylpheed options ;) But there's no general way to
instruct these MUAs to automatically default to 'reply-to-list' for
any reply to a list mail (i.e., any mail with a 'List-ID: ' header),
correct?

Celejar

[toc] | [prev] | [next] | [standalone]

#229506 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

On Tue, 8 Dec 2020 19:41:42 -0500
Celejar <celejar@gmail.com> wrote:

> Ah, yes. Those are Sylpheed options ;) But there's no general way to
> instruct these MUAs to automatically default to 'reply-to-list' for
> any reply to a list mail (i.e., any mail with a 'List-ID: ' header),
> correct?

Try Configuration -> Preferences -> Writing -> Reply button invokes
mailing list reply.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#229509 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

On Tue, 8 Dec 2020 17:51:13 -0700
Charles Curley <charlescurley@charlescurley.com> wrote:

> On Tue, 8 Dec 2020 19:41:42 -0500
> Celejar <celejar@gmail.com> wrote:
> 
> > Ah, yes. Those are Sylpheed options ;) But there's no general way to
> > instruct these MUAs to automatically default to 'reply-to-list' for
> > any reply to a list mail (i.e., any mail with a 'List-ID: ' header),
> > correct?
> 
> Try Configuration -> Preferences -> Writing -> Reply button invokes
> mailing list reply.

Under Preferences, I have a Compose tab, but no Writing one, and the
Writing one doesn't contain the option you mention. I guess this is a
Claws improvement.

Celejar

[toc] | [prev] | [next] | [standalone]

#229525 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

[Multipart message — attachments visible in raw view] — view raw

On Tue, 8 Dec 2020 20:37:37 -0500
Celejar <celejar@gmail.com> wrote:

Hello Celejar,

>Under Preferences, I have a Compose tab, but no Writing one, and the

Writing is under Compose;  This is in Claws - Sylpheed may well differ.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
We are the chosen
Changed - Judgement Centre

[toc] | [prev] | [next] | [standalone]

#229573 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

On Wed, 9 Dec 2020 08:04:19 +0000
Brad Rogers <brad@fineby.me.uk> wrote:

> On Tue, 8 Dec 2020 20:37:37 -0500
> Celejar <celejar@gmail.com> wrote:
> 
> Hello Celejar,
> 
> >Under Preferences, I have a Compose tab, but no Writing one, and the
> 
> Writing is under Compose;  This is in Claws - Sylpheed may well differ.

Yes; as I said, I'm pretty sure we've found one of the actual
differences between Sylpheed and Claws. In Sylpheed, there's no
"Writing" under "Compose".

Celejar

[toc] | [prev] | [next] | [standalone]

#229671 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

Thank you Charles,

Anyway do you have idea you can help me in resolving the graphics issue?

Should I post this again as a separate thread to gather more expertise?

Bests Regards,
Guyenne

[toc] | [prev] | [next] | [standalone]

#229673 — Re: Replying. [was Re: AMD GPU Sea Islands Problem]

On Fri, 11 Dec 2020 20:11:12 +0000
Guyenne Tsui <guyenne@gmail.com> wrote:

> Thank you Charles,

You're welcome.

> 
> Anyway do you have idea you can help me in resolving the graphics
> issue?

It's outside my expertise, or I would have replied with something. The
only thing I can think of is to try the backports kernel.

> 
> Should I post this again as a separate thread to gather more
> expertise?

It might help.

You might also try the vendor's web site. Not that I expect a lot from
them; most vendors don't care all that much about Linux. Phoronix.com
might be useful, but that's mostly a news site.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#229373

Guyenne Tsui composed on 2020-12-05 14:11 (UTC):

> Whenever I try to do any form rendering using the dGPU, the software 
> just hangs and become inresponsive. My kernel based on `uname -v` is '#1 
> SMP Debian 5.9.9-1 (2020-11-19)'.

What is "form rendering"? Which Sea Islands do you have? Which Debian are you
using? Which DDX driver are you using? Do you have in your grub stanzas
radeon.cik_support=0 amdgpu.cik_support=1 ???

How might I try to reproduce this with my Sea Islands IGP?
# inxi -GISay
System:
  Host: asa88 Kernel: 5.9.0-4-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.0
  parameters:...noresume mitigations=auto consoleblank=0
  radeon.cik_support=0 amdgpu.cik_support=1
  Desktop: Trinity R14.0.10 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM
  Distro: Debian GNU/Linux bullseye/sid
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu
  v: kernel alternate: radeon bus ID: 00:01.0 chip ID: 1002:130f
  Display: x11 server: X.Org 1.20.8 driver: modesetting display ID: :0
  screens: 1
  Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0")
  s-diag: 479mm (18.9")
  Monitor-1: DP-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  OpenGL: renderer: AMD KAVERI (DRM 3.39.0 5.9.0-4-amd64 LLVM 11.0.0)
  v: 4.6 Mesa 20.2.3 direct render: Yes
Info:...Shell: Bash v: 5.1.0-rc3 running in: konsole inxi: 3.1.0
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#229403

> What is "form rendering"?
Sorry I meant "form of rendering"

> Which Sea Islands do you have?
Radeon R5 M430. I checked it again and it seems to be Southern Islands. 
I am not sure.

> Which Debian are you using?
Debian Testing

> Which DDX driver are you using?
I am not sure what is DDX driver. I installed firmware-amd-graphics in 
past and it worked automatically. However, a recent update broke it.

> Do you have in your grub stanzas radeon.cik_support=0 amdgpu.cik_support=1 ???

I tried both `radeon.cik_support=0 amdgpu.cik_support=0` and 
`radeon.si_support=0 amdgpu.si_support=1`. It seems that the latter 
works from the looks of `lspci -k`.

[toc] | [prev] | [next] | [standalone]

#229677

Guyenne Tsui composed on 2020-12-06 22:17 (UTC):

>> What is "form rendering"?

> Sorry I meant "form of rendering"

>> Which Sea Islands do you have?

> Radeon R5 M430. I checked it again and it seems to be Southern Islands. 
> I am not sure.

>> Which Debian are you using?

> Debian Testing

>> Which DDX driver are you using?

> I am not sure what is DDX driver. I installed firmware-amd-graphics in 
> past and it worked automatically. However, a recent update broke it.

DDX means Device Dependent X.

I wasn't aware that amdgpu would ever work automatically with sea islands.
Normally it needs radeon.si_support=0 and amdgpu.si_support=1 to use it.

>> Do you have in your grub stanzas radeon.cik_support=0 amdgpu.cik_support=1 ???

> I tried both `radeon.cik_support=0 amdgpu.cik_support=0` and 
> `radeon.si_support=0 amdgpu.si_support=1`. It seems that the latter 
> works from the looks of `lspci -k`.

Try purging xserver-xorg-video-amdgpu and xserver-xorg-video-ati, then restarting
X. That should automatically result in using the modesetting X driver. It does for
my sea islands. If it's OK, either keep it that way, or try reinstalling only
xserver-xorg-video-amdgpu.
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#229706

> Try purging xserver-xorg-video-amdgpu and xserver-xorg-video-ati, then restarting
> X. That should automatically result in using the modesetting X driver. It does for
> my sea islands. If it's OK, either keep it that way, or try reinstalling only
> xserver-xorg-video-amdgpu.
I tried to purge xserver-xorg-video-amdgpu and xserver-xorg-video-ati. 
However it offered me to remove my entire desktop environment. So I 
hesitated. I had a Pop!_OS installed on my drive which also encountered 
the same graphical issues. So I instead installed a new Pop!_OS LTS on 
my drive. The new Pop!_OS also froze when the command `DRI_PRIME=1 
glxgears -fullscreen` is passed. This should indicate that the graphical 
issue is not a result of my system tinkering. Since Pop!_OS is a 
derivative of Ubuntu of which is a derivative of Debian, I think the 
issue is either in Debian or upstream. I purged `firmware-amd-graphics` 
but the graphical issue still persists. I cannot seem to locate which 
package is causing the bug, so I am not sure how to file such an 
ambiguous bug.

Bests Regards,
Guyenne

[toc] | [prev] | [next] | [standalone]

#229716

[Multipart message — attachments visible in raw view] — view raw

On Sb, 12 dec 20, 16:23:40, Guyenne Tsui wrote:
> > Try purging xserver-xorg-video-amdgpu and xserver-xorg-video-ati, then restarting
> > X. That should automatically result in using the modesetting X driver. It does for
> > my sea islands. If it's OK, either keep it that way, or try reinstalling only
> > xserver-xorg-video-amdgpu.
> I tried to purge xserver-xorg-video-amdgpu and xserver-xorg-video-ati.
> However it offered me to remove my entire desktop environment. So I
> hesitated. 

There's probably a workaround, please show the full output (copy-paste) 
from what 'apt' is proposing when trying to purge those packages.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#229998

#apt purge xserver-xorg-video-amdgpu xserver-xorg-video-ati:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
   apper apper-data espeak-ng-data fonts-symbola gir1.2-atspi-2.0 
gir1.2-wnck-3.0 hyphen-en-us kdeaccessibility kmag kmousetool kmouth 
libatk-adaptor libbrlapi0.8
   libc-ares2 libdotconf0 libespeak-ng1 libjs-highlight.js libnode72 
libpcaudio0 libqaccessibilityclient-qt5-0 libreoffice-help-common 
libreoffice-help-en-us
   libreoffice-kf5 libreoffice-plasma libreoffice-qt5 libsonic0 
libstartup-notification0 libu2f-udev libwnck-3-0 libwnck-3-common 
mythes-en-us node-normalize.css
   nodejs nodejs-doc orca perl-tk policykit-1-gnome print-manager 
python3-brlapi python3-louis python3-pyatspi python3-speechd python3-xdg 
qtgstreamer-plugins-qt5
   sound-icons speech-dispatcher speech-dispatcher-audio-plugins 
speech-dispatcher-espeak-ng x11-apps x11-session-utils xbrlapi xinit 
xkbset xorg
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
   task-desktop* task-kde-desktop* xserver-xorg-video-all* 
xserver-xorg-video-amdgpu* xserver-xorg-video-ati*
0 upgraded, 0 newly installed, 5 to remove and 1 not upgraded.
After this operation, 712 kB disk space will be freed.
Do you want to continue? [Y/n]

Anyway I solved the initial issue. Apparently, the boot parameter 
`radeon.dpm=0` solved the initial issue. Apparently, on newer kernels 
(testing) the boot parameter is automatically set 1 and caused issues. 
However I checked xorg website and they stated dpm is compatible with 
Southern Islands, but I am not sure.

[toc] | [prev] | [next] | [standalone]

#230001

Guyenne Tsui composed on 2020-12-26 20:35 (UTC):

> #apt purge xserver-xorg-video-amdgpu xserver-xorg-video-ati:
...
> The following packages will be REMOVED:
>    task-desktop* task-kde-desktop* xserver-xorg-video-all* 

Those three are meta-packages, so nothing important would be lost.

> xserver-xorg-video-amdgpu* xserver-xorg-video-ati*
> 0 upgraded, 0 newly installed, 5 to remove and 1 not upgraded.
...
> Anyway I solved the initial issue. Apparently, the boot parameter 
> `radeon.dpm=0` solved the initial issue. Apparently, on newer kernels 
> (testing) the boot parameter is automatically set 1 and caused issues. 
> However I checked xorg website and they stated dpm is compatible with 
> Southern Islands, but I am not sure.

I don't remember seeing that one before. Radeon Dynamic Power Management.
Nice you found it!
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#230002

On 12/26/20 8:51 PM, Felix Miata wrote:
> I don't remember seeing that one before. Radeon Dynamic Power Management.
> Nice you found it!

Should I file a bug? I mean it may be a problem with dpm or a 
compatibility issue that users have to figure it out themselves?

[toc] | [prev] | [next] | [standalone]

#230003

Guyenne Tsui composed on 2020-12-26 21:37 (UTC):

> Felix Miata wrote:

>> I don't remember seeing that one before. Radeon Dynamic Power Management.
>> Nice you found it!

> Should I file a bug? I mean it may be a problem with dpm or a 
> compatibility issue that users have to figure it out themselves?

It might turn out to be pointless. Users of older hardware, particularly Southern
Islands and Sea Islands users, seem to get short shrifted with disappointing
frequency by developers. I saw some talk a while back about removing GCN1
(Southern Islands) and GCN2 (Sea Islands) support from the AMDGPU DDX. I'm not
sure what you encountered could be termed a bug. Of course if you don't, there's a
good chance it would never be noticed by any developer.
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#230004

[ Beware: User of Core 2 Duo machines talking here.  ]

> It might turn out to be pointless.

I strongly disagree here: it's by reporting such bugs that you can show
there is still interest in supporting such hardware.

> Users of older hardware, particularly Southern Islands and Sea Islands
> users, seem to get short shrifted with disappointing frequency
> by developers.

I'd find it very disappointing if hardware as recent as that would be
already considered too old to support satisfactorily.

I can understand that the developers may not want to spend much time
improving support for that hardware, but it should at least stay about
as good as it was in the past.

> I'm not sure what you encountered could be termed a bug.  Of course if
> you don't, there's a good chance it would never be noticed by
> any developer.

That's why it's important to report it.
Since it used to work, it's probably just an oversight.


        Stefan

[toc] | [prev] | [next] | [standalone]

#229720

[Multipart message — attachments visible in raw view] — view raw

On 12.12.2020 21:23, Guyenne Tsui wrote:
>> Try purging xserver-xorg-video-amdgpu and xserver-xorg-video-ati, 
>> then restarting
>> X. That should automatically result in using the modesetting X 
>> driver. It does for
>> my sea islands. If it's OK, either keep it that way, or try 
>> reinstalling only
>> xserver-xorg-video-amdgpu.
> I tried to purge xserver-xorg-video-amdgpu and xserver-xorg-video-ati. 
> However it offered me to remove my entire desktop environment. So I 
> hesitated. I had a Pop!_OS installed on my drive which also 
> encountered the same graphical issues. So I instead installed a new 
> Pop!_OS LTS on my drive. The new Pop!_OS also froze when the command 
> `DRI_PRIME=1 glxgears -fullscreen` is passed. This should indicate 
> that the graphical issue is not a result of my system tinkering. Since 
> Pop!_OS is a derivative of Ubuntu of which is a derivative of Debian, 
> I think the issue is either in Debian or upstream. I purged 
> `firmware-amd-graphics` but the graphical issue still persists. I 
> cannot seem to locate which package is causing the bug, so I am not 
> sure how to file such an ambiguous bug.
>
> Bests Regards,
> Guyenne
>
If you experience the same behavior on different OSs, then it is 
possible GPU itself is faulty.
Since your GPU is muxless, it relies on CPU integrated graphics to work 
with display, so only when you offload some task (by using DRI_PRIME=1) 
to discrete GPU it fails.
If I was in your shoes I'd install Windows (evaluation version, no need 
to purchase or activate anything) with AMD WHQL drivers and ran some 
benchmarks just to know for sure if GPU is actually working.

If you still want to continue as-is I'd suggest to reinstall both 
"xserver-xorg-video-amdgpu" and "xserver-xorg-video-ati" packages and 
install "firmware-amd-graphics", but blacklist "radeon" module, to 
prevent it from loading, just to be sure we use "amdgpu" driver. And if 
that won't work blacklist "amdgpu" module instead.
Also delete kernel parameters for "radeon" or\and "amdgpu", since we 
blacklisting modules, defaults should be fine.

Send us outputs from these commands:
     $ xrandr --listproviders
     $ glxinfo | grep -e "OpenGL" -e "glx"
     $ DRI_PRIME=1 glxinfo | grep -e "OpenGL" -e "glx"


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#229999

The issue only occurs with ditros based on Debian Testing, such as 
Pop!_OS. This does not occur with my Debian Stable.

Anyway I solved the initial issue. Apparently, the boot parameter 
`radeon.dpm=0` solved the initial issue. Apparently, on newer kernels 
(testing) the boot parameter is automatically set 1 and caused issues. 
However I checked xorg website and they stated dpm is compatible with 
Southern Islands, but I am not sure.

Should I file a bug? If so where?

[toc] | [prev] | [next] | [standalone]

#229728

Guyenne Tsui composed on 2020-12-12 16:23 (UTC):

> I tried to purge xserver-xorg-video-amdgpu and xserver-xorg-video-ati. 
> However it offered me to remove my entire desktop environment. So I 
> hesitated. I had a Pop!_OS installed on my drive which also encountered 
> the same graphical issues. So I instead installed a new Pop!_OS LTS on 
> my drive. The new Pop!_OS also froze when the command `DRI_PRIME=1 
> glxgears -fullscreen` is passed. This should indicate that the graphical 
> issue is not a result of my system tinkering. Since Pop!_OS is a 
> derivative of Ubuntu of which is a derivative of Debian, I think the 
> issue is either in Debian or upstream. I purged `firmware-amd-graphics` 
> but the graphical issue still persists. I cannot seem to locate which 
> package is causing the bug, so I am not sure how to file such an 
> ambiguous bug.

What follows is from a GCN#1, like yours. xserver-xorg-video-amdgpu and
firmware-amd-graphics are installed. xserver-xorg-video-ati is not installed.
'DRI_PRIME=1 glxgears -fullscreen` works as expected, as well as the rest of X.

# uname -a
Linux fi965 5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 (2020-11-27) x86_64 GNU/Linux
# inxi -GISay
System:
  Host: fi965 Kernel: 5.9.0-4-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.0
  parameters:...mitigations=auto consoleblank=0 plymouth.enable=0
    radeon.si_support=0 amdgpu.si_support=1
  Desktop: Trinity R14.0.10 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM
  Distro: Debian GNU/Linux bullseye/sid
Graphics:
  Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM]
  vendor: Dell driver: amdgpu v: kernel alternate: radeon bus ID: 01:00.0

    chip ID: 1002:6611

  Display: x11 server: X.Org 1.20.10 driver: amdgpu
  unloaded: fbdev,modesetting,vesa alternate: ati display ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 120 s-size: 541x304mm (21.3x12.0")
  s-diag: 621mm (24.4")
  Monitor-1: DisplayPort-0 res: 2560x1440 hz: 60 dpi: 109
  size: 598x336mm (23.5x13.2") diag: 686mm (27")
  OpenGL: renderer: AMD Radeon HD 8500 Series (OLAND DRM 3.39.0 5.9.0-4-amd64
  LLVM 11.0.0)
  v: 4.6 Mesa 20.2.4 direct render: Yes
Info:...Shell: Bash v: 5.1.0-rc3 running in: konsole inxi: 3.1.09
# lspci -nnk | grep -A3 VGA
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM] [1002:6611]
        Subsystem: Dell Radeon R5 240 OEM [1028:210b]
        Kernel driver in use: amdgpu
        Kernel modules: radeon, amdgpu
# xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x53 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 2 associated providers: 0 name:AMD Radeon HD 8500 Series @ pci:0000:01:00.0

These commands produce identical output.
     $ glxinfo | grep -e "OpenGL" -e "glx"
     $ DRI_PRIME=1 glxinfo | grep -e "OpenGL" -e "glx"

/etc/X11/xorg.con* contains nothing that is graphics-related.
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web