Announcement

Collapse
No announcement yet.

RadeonSI Disables SDMA For Polaris To Fix Corruption Bugs

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

  • Chewi
    replied
    I had hoped that this would fix HDAO in Alien: Isolation, which has been showing weird corruption for a while now. No such luck. The game also freezes up after a while due to some GPU-related issue, which never used to happen. I'm hoping this or the recent reset fixes will help there.

    Leave a comment:


  • duby229
    replied
    Originally posted by brent View Post
    No, rolling release doesn't really help here either. The latest released kernel is broken with Intel in various ways after all. Unless you consider "rolling release" to mean running the very latest RCs, but that's quite crazy.
    And AMD has to worry about Intel bugs how? He was complaining about the complexity of backporting to stable distro's, hence old Kernel's and the problems associated with getting that work upstreamed. The solutions to that is simply to focus on the latest release alone and let them fools have their so called "stable" releases. It's what they want after all. It was they who decided to lock in old versions, so give em exactly what they decided on. In mean time AMD can implement bug fixes and features in the latest code and when end users experience bugs AMD can recommend a rolling release distro where that latest code is available.

    Then the onus is not on AMD to do impossible things like backport code that can't be upstreamed and instead the onus gets put on the distro to update versions. That's the best possible scenario for everyone. It reduces AMD's workload and gives users actually stable environments to work in.
    Last edited by duby229; 09 January 2020, 07:36 PM.

    Leave a comment:


  • brent
    replied
    No, rolling release doesn't really help here either. The latest released kernel is broken with Intel in various ways after all. Unless you consider "rolling release" to mean running the very latest RCs, but that's quite crazy.

    Leave a comment:


  • duby229
    replied
    Originally posted by agd5f View Post

    It's hard for everyone. The current kernel model makes this very difficult. There are "stable" kernel branches, but very few distros use them. Just about every distro picks their own kernel and them backports stuff to it. Released kernels only allow bug fixes. If you have a bug fix, in some cases it's not feasible to backport it to a previously released kernel because it depends on a major driver refactoring or some new feature that's not allowed in the released kernel. Then you have to test all of the kernels you want to support. The combination of currently active kernels and "stable" kernels and distro kernels is huge. And that is just the kernel. Add the same variations with various userspace components and the combinations are even bigger.
    Yeah, I can certainly understand your frustrations with so called "stable" distro's.

    Though it's my opinion that it's not a problem with the kernels distribution model, it's a problem with quite a few distro's release model. Basically all major upstream projects are rolling release based models and so the only kind of linux distro that makes any sense is rolling release based distro's. The problems you describe don't exist for them. My advice is just concentrate on supporting the most recent code on the newest git and say screw it to those so called stable distro's. They aren't stable and there's nothing you can do about that. "Stable" in this case means that they don't change, so let them have what they want and don't worry about it.

    You need to suggest end users use rolling release distro's where they can get the newest code.

    EDIT: The only way the "stable" distribution model works is if the kernel implements a "stable" internal interface and that's never gonna happen. You can't do anything about that. So the only option is to recommend a rolling release distro, it's what makes sense.
    Last edited by duby229; 09 January 2020, 01:58 PM.

    Leave a comment:


  • agd5f
    replied
    Originally posted by brent View Post
    I don't know why, but Intel developers do not manage to backport workarounds/fixes to stable kernels. This is really frustrating.
    It's hard for everyone. The current kernel model makes this very difficult. There are "stable" kernel branches, but very few distros use them. Just about every distro picks their own kernel and them backports stuff to it. Released kernels only allow bug fixes. If you have a bug fix, in some cases it's not feasible to backport it to a previously released kernel because it depends on a major driver refactoring or some new feature that's not allowed in the released kernel. Then you have to test all of the kernels you want to support. The combination of currently active kernels and "stable" kernels and distro kernels is huge. And that is just the kernel. Add the same variations with various userspace components and the combinations are even bigger.

    Leave a comment:


  • aufkrawall
    replied
    I'm also not overly happy with my Gemini Lake SoC. Custom EDID not working, stutter in mpv Wayland, that terrible RC6 bug management, equally terrible frame buffer compression bug management...
    The experience with Polaris, however, is just getting better and better (slowly, but still).

    If AMD guys now would take a look at the Navi issue I reported regarding hardware cursor + vsync, agd5f I'd probably order a Navi GPU in the not too distant future.

    Leave a comment:


  • brent
    replied
    Intel GPUs are not a magic land of stability either like some here tend to imply, by the way. I have a total of three issues right now:

    * Panel self-refresh is enabled by i915 by default, but it does not work well (flickering). I have to disable it manually with a kernel flag. The downside is significantly increased power usage.
    * Recent kernels suffer from broken RC6 sleep state, resulting in extremely (!) increased power usage
    * Kernel 5.4 also suffers from random GPU hangs on many systems, mine included

    I don't know why, but Intel developers do not manage to backport workarounds/fixes to stable kernels. This is really frustrating.

    Leave a comment:


  • PuckPoltergeist
    replied
    Originally posted by Xicronic View Post
    Disabling and never fixing seems like a trend for AMD. Intel GPUs can't come soon enough...
    How long did it take until RC6 worked? At least for one generation of GPUs?

    Leave a comment:


  • Marc Driftmeyer
    replied
    Patchwork appears to be already showing fixes on SDMA.

    Leave a comment:


  • geearf
    replied
    Originally posted by nuetzel View Post

    I don't 'see' any on Polaris 20 (8 GB version) so far.
    Even better then ever (with latest optimizations).
    Look here: #2
    Good enough for me, thank you!

    Leave a comment:

Working...
X