• auroz@lemmy.sdf.org
      link
      fedilink
      arrow-up
      18
      ·
      4 个月前

      I think the issue of gaming on linux hasn’t been performance for a while now (native and wine/proton performance can often beat windows) but compatibility - some games still can’t run on linux due to DRM, anti-cheat, etc. Things are gradually improving but I think that’s the main barrier for the time being

      • recursive_recursion [they/them]@programming.devOP
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        4 个月前

        if the main barrier for entry seems to be compatibility (which is totally fair as DRM and anti-cheat can be a real pain in the ass) hopefully wine/proton (aka Steam) can come in clutch to help solve most if not all of these related issues (or anyone else that has the know to and desire to create another copyleft compatibility layer)

        • auroz@lemmy.sdf.org
          link
          fedilink
          arrow-up
          8
          ·
          4 个月前

          The problem is that modern DRM/anti-cheat often works at the kernel level, or by scanning the entire filesystem and running processes. They don’t work on linux by design, so the main route to compatibility is showing that there are enough people gaming on linux that they should seek other options for DRM and anti-cheat

          • recursive_recursion [they/them]@programming.devOP
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            4 个月前

            just curious but what do you think about Virtualization such as QEMU/KVM and Looking Glass?

            I’m a bit uninformed in this venn diagram and this will probably come off as stupid question but:

            What’s the likelihood that modern DRM and/or anti-cheat could detect that it’s being run inside a VM? (I’m gonna guess pretty high unfortunately)


            Edit:
            rip, guess dual booting is still the closest solution atm (for those who play DRM/anti-cheat locked games)

            • auroz@lemmy.sdf.org
              link
              fedilink
              arrow-up
              6
              ·
              4 个月前

              Unfortunately very high, especially with modern systems using “trusted platform module” (TPM) hardware that can tell the software exactly what’s running, at a higher privilege level than the OS

    • Jure Repinc@lemmy.ml
      link
      fedilink
      English
      arrow-up
      4
      ·
      4 个月前

      It’s totaly messed up in general and has been for a long time. They try to hack it for the new CPU model and stab you in the back for older CPUs, I’d say it is FUBAR.

  • Lets_Eat_Grandma@lemm.ee
    link
    fedilink
    English
    arrow-up
    4
    ·
    4 个月前

    Two problems:

    • Benchmarks are not real world performance.

    • Video card drivers are still not up to snuff as they are with windows, to the best of my knowledge. (don’t kill me if i’m wrong!)

    • schizo@forum.uncomfortable.business
      link
      fedilink
      English
      arrow-up
      5
      ·
      4 个月前

      It depends: if you’re talking rasterization performance, then yeah, they’re pretty much on parity.

      If you’re talking about all the other things a video card does that’s not strictly make-pixel-light-up, then it’s very much a mixed bag.

    • Jure Repinc@lemmy.ml
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      4 个月前

      From my experince AMD drivers are pretty close, I’d even say slightly better on GNU/Linux, definitely more stable and consistent. For Nvidia, yeah they are bad at supporting GNU/Linux. Improved a lot through the years but still not there. For Intel, well not exactly an option for gaming, at least not the integrated GPUs I have used so far, but still better than in Windows in a similar way as in AMD case.

      P.S. Another great thing with libre/opensource GNU/Linux drivers: When you report a bug with Mesa3D drivers the bug is quite quickly fixed, especially when you can provide them with backtrace and/or Vulkan/OpenGL API trace. Doing a bisect of source code commits amd identifying the commit that introduced a regression also help a great deal. Good luck doing the same with closed/Windows drivers: you can wait for years and no fix.