‹ BackHN Continuity

Thread

The work by Valve's Timur Kristóf on improving old AMD GPUs on Linux

472 points · 97 comments · speckx

  1. wewewedxfgdf · · focus · HN ↗
    If only AMD did this.
    1. bigyabai · · focus · HN ↗
      AMD supports Mesa precisely so that enthusiasts can do this.

      Nvidia doesn't, and their Vulkan stack underperforms on Linux quite significantly.

      1. pjmlp · · focus · HN ↗
        Except VFX and Hollywood have no qualms using proprietary drivers.
        1. simoncion · · focus · HN ↗
          Even proprietary drivers can use Mesa. Most of Mesa is MIT-licensed.

          It's just that Nvidia doesn't care much about Linux, and -as always- Nvidia ignores what everyone else is doing and does their own thing. Sometimes doing their own thing works out really well in the short run, but -long term- they always fall behind.

          1. AceJohnny2 · · focus · HN ↗
            > It's just that Nvidia doesn't care much about Linux

            Nvidia cares a lot about Linux. Just... on their terms.

            1. hobo123 · · focus · HN ↗
              Terms which famously caused Linus Torvalds to tell them to FU.
              1. bigyabai · · focus · HN ↗
                With fairness; some things have changed.

                The biggest issue was Nvidia's insistence on buffer management with EGLStreams instead of GBM, which broke a lot of desktops. But they forfeit that fight ~4 years ago.

                1. torginus · · focus · HN ↗
                  EGLStreams actually was(is) a pretty good API, and I think most compositors would've had a much better time if they decided to implement that on top of GBM.

                  To summarize the difference between the two, with EGLStreams, you just request a buffer to draw into from a pool, then once you're done, you just submit it, thereby relinquishing control of it.

                  With GBM, you explicitly need to manage the lifetime and access of your buffers, making sure you don't leak or accidentally write it when the GPU/driver tries to, there's no clear ownership, and you have to handle surfaces for double/triple buffering.

                  It's a much lower level API, and much harder for drivers and app developers to get right, which was no doubt responsible for many years of buggy Wayland compositors - in fact, basically there wasn't a single correct implementation until Valve built Gamescope/their wlroots-based KWin fork and did a bunch of driver work.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.