Announcement

Collapse
No announcement yet.

A Number Of AMDGPU DRM Fixes Prepped Ahead Of Linux 4.19

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • A Number Of AMDGPU DRM Fixes Prepped Ahead Of Linux 4.19

    Phoronix: A Number Of AMDGPU DRM Fixes Prepped Ahead Of Linux 4.19

    Following AMD staging numerous AMDGPU DRM improvements in DRM-Next for Linux 4.19, they have moved onto further testing this code and providing various fixes for some of the early fallout to these changes ahead of the next kernel cycle...

    http://www.phoronix.com/scan.php?pag...Linux-4.19-DRM

  • itoffshore
    replied
    Originally posted by dwagner View Post
    I still cannot reach uptimes of more than a few hours with the most recent kernels and amdgpu on a RX460. The old 4.13 kernel had a mean time between crashes of about two days, newer kernels are much less stable for me.
    The MSI RX 560 Aero ITX 4GB OC has been running great for me in Manjaro XFCE with the linux-hardened kernel & no login manager (i.e running Xorg as a user NOT root)

    MSI RX 570 Armor 8GB also running without any problems

    Leave a comment:


  • Mez'
    replied
    I am very happy with amdgpu since 4.18 first RCs. I am now on an uptime of 32 days (1+ month) for the first time in 18 months of tinkering with Kaveri (A10-7860K) then RX 560 (Baffin Pro/Polaris 21).
    I can suspend/resume seamlessly, I can turn off/on the screen again without freeze and I can switch input source of the AV receiver to TV and back without freeze either. All the bugs I complained about have been ironed out and I'm now a very satisfied user. I've complained my fair share, but you gotta give it when hard work is bearing fruits.

    Kudos to AMD! Thanks.

    It's great to see more work coming in though. Keep it flowing.

    Leave a comment:


  • dwagner
    replied
    Originally posted by shmerl View Post
    Are you using latest AMD firmware?
    One of my computers (with RX 460) had very similar symptoms, and using newest firmware fixed them.
    Of course I use this latest firmware (which, btw., is at this time also the version that Arch Linux distributes), but that does not help me.

    Leave a comment:


  • M@GOid
    replied
    Originally posted by Brisse View Post

    I used to run Ubuntu 17.10 with custom kernels including DC amongst other things before moving on to Debian Sid and I had the same issue there, but yea, I might try 18.04 anyway.

    One thing I'm noticing though is that whenever I bring this up, someone says they dont have the issue and they always have a Polaris GPU. Might be specific to my hardware.
    Had you tried hocking it up with a TV (in HDMI)? Maybe is the monitor's fault. Mine have a poor DAC, so I changed to another setup.

    Leave a comment:


  • Brisse
    replied
    Originally posted by [email protected] View Post

    A couple weeks ago I was sucessifully using a Benq monitor (Displayport) as a audio output for my stereo speakers, with a RX 570 in a Kubuntu 18.04 installation. Maybe you can try Kubuntu via a USB flashdrive to check if the problem persists.
    I used to run Ubuntu 17.10 with custom kernels including DC amongst other things before moving on to Debian Sid and I had the same issue there, but yea, I might try 18.04 anyway.

    One thing I'm noticing though is that whenever I bring this up, someone says they dont have the issue and they always have a Polaris GPU. Might be specific to my hardware.

    Leave a comment:


  • M@GOid
    replied
    Originally posted by Brisse View Post

    I'm no developer or expert on this but the way I see it:

    Windows: Has a sample rate setting (def. 48khz) and resamples everything to that rate regardless of the source. It reports that my monitor can take 32, 44.1 and 48khz (https://imgur.com/kjfVKmH) and if I change the default of 48khz to either of these I still get audio.

    Pulse Audio + ALSA: Defaults to 44.1khz but also has an "alternate rate" setting (def. 48khz) and automatically selects one of these rates depending on the first source it sees to try to stay "bit perfect" if possible, depending on what the output device supports. This works fine on several audio cards I've tested, including the motherboard internal audio which I'm currently using.

    When I select display port as my audio device on Linux, I run into problems. Say I want to listen to some music in Rhythmbox which is typically 44.1khz. No audio from the speakers. If I then stop the music and open a video (typically 48khz) in MPV then I can hear the audio fine. If I start playing music in Rhythmbox while the video is playing, then the music will have to be resampled to 48khz to match the audio stream from the video, and this does make the music audible. I can also reconfigure pulse to resample everything to 48khz to work around this issue, but that's not a bug fix, that's just a workaround.

    So it seems to me there's an issue somewhere. The monitor should be able to take 44.1khz, and if it didn't then ALSA would have to be aware that it doesn't, and if that's the case then the device driver (would that be AMDGPU DC in this case?) will have to tell ALSA that this output device only accepts 48khz.

    Sorry for the wall of text. Anyone know where the best place to report this would be?
    A couple weeks ago I was sucessifully using a Benq monitor (Displayport) as a audio output for my stereo speakers, with a RX 570 in a Kubuntu 18.04 installation. Maybe you can try Kubuntu via a USB flashdrive to check if the problem persists.

    Leave a comment:


  • humbug
    replied
    Great to see some love for gcn 1.1

    Leave a comment:


  • geearf
    replied
    It'd be nice to have powerplay on GCN 1 as well

    Leave a comment:


  • shmerl
    replied
    Originally posted by dwagner View Post
    with mpv, the amdgpu driver reproduceably crashes before the 10 minute video is over. And that even with --vo=xv, so this isn't about stressing opengl.
    Are you using latest AMD firmware?

    One of my computers (with RX 460) had very similar symptoms, and using newest firmware fixed them.

    Leave a comment:

Working...
X