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

  • dwagner
    replied
    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.

    I recently found that if I replay the output of
    youtube-dl -f 248+251 'https://www.youtube.com/watch?v=kYKE78Pcjog'
    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.

    (For more details, see https://bugs.freedesktop.org/show_bug.cgi?id=107152 )

    Leave a comment:


  • agd5f
    replied
    The GPU driver is basically just a conduit for the audio. It passes the display/receiver audio caps (extracted from in the EDID) to the audio driver and enables the audio stream within the overall video stream. The audio driver then reads the display caps and exposes them to the user who can then request the type of stream they want to send. At that point once the display is up, it's up to the audio driver to send whatever stream they've worked out based on the display caps. I would start with ALSA.

    Leave a comment:


  • Brisse
    replied
    Originally posted by agd5f View Post

    Sounds like it might be a audio driver or application issue. Most HDA codecs only support 48khz. The CPU has to do the re-sampling for other rates I think.
    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?

    Leave a comment:


  • agd5f
    replied
    Originally posted by Brisse View Post

    Uh? Not sure I understand. AMDGPU DC including HDMI and DP audio was mainlined in 4.15. My issue is that it only works for 48khz content, but not for 44.1khz and it doesn't seem like anyone is looking into it. Are you saying that 4.19 has a fix for this bug?
    Sounds like it might be a audio driver or application issue. Most HDA codecs only support 48khz. The CPU has to do the re-sampling for other rates I think.

    Leave a comment:


  • shmerl
    replied
    So amdgpu Vega blanking woes will only be fixed in 4.19+? What about DisplayPort / Wayland issues?

    Leave a comment:


  • wizard69
    replied
    Originally posted by makam View Post
    So raven ridge will hopefully be stable in autumn?
    On Ryzen Mobile I would call Linux very usable. My system can't Suspend (varies a bit with the kernel I'm running + Fedora updates) and does have an occasional keyboard hang. However for my usage (programming, web, and video watching) it does very well. It has literally gotten better with each update from Fedora.

    A quick edit: some of the problem s that are showing up might not even be AMD related, I've seen reports of various forums where Intel hardware has had similar issues.

    Leave a comment:


  • Brisse
    replied
    Originally posted by Marc Driftmeyer View Post

    Yes, as in it won't be mainlined until 4.19.
    Uh? Not sure I understand. AMDGPU DC including HDMI and DP audio was mainlined in 4.15. My issue is that it only works for 48khz content, but not for 44.1khz and it doesn't seem like anyone is looking into it. Are you saying that 4.19 has a fix for this bug?

    Leave a comment:


  • Marc Driftmeyer
    replied
    Originally posted by Brisse View Post
    Still not getting any audio from the display port on my Fury to my MG279Q monitor when playing 44.1khz content as of kernel 4.17.8. Always worked fine on Windows so there's got to be some issue somewhere.
    Yes, as in it won't be mainlined until 4.19.

    Leave a comment:


  • Peter Fodrek
    replied
    I feel like in Czech Kingdom because of surnames in the commit
    Christian König
    Colin Ian King and
    Thomas Zimmermann
    because most famous Czech virtual inventor Jára Cimrman (uitgesproken als het Duitse Zimmermann) https://de.wikipedia.org/wiki/J%C3%A1ra_Cimrman


    Leave a comment:


  • davidbepo
    replied
    Originally posted by makam View Post
    So raven ridge will hopefully be stable in autumn?
    its already stable for me

    Leave a comment:

Working...
X