Graphical boot menus are timing out before AMDGPU can load.
    • boredsquirrel@slrpnk.net
      5·
      2 months ago

      On an Intel machine, this makes me want to compile my kernel so much

      I should learn how to compile RPM kernels on COPR

      • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
        5·
        2 months ago

        Compiling has never been the hard part. The challenge is making it through the entire configuration menu system before succumbing to the urge to gouge your own eyes out with blunt sticks.

        Once that’s done, kick off make take a long break; it’ll be compiled by the time you get back to it.

        I hear build times are getting longer with the Rust parts, though, so do it soon before you need mainframe access to get a compile within your lifetime.

        • boredsquirrel@slrpnk.net
          2·
          2 months ago

          The thing is I need to configure, compile, package, sign and then layer, because I am on Fedora Atomic (and because that is the correct way)

          And I dont know many of the steps in the middle.

          A Github runner for this would be great, like a template where people can choose what kernel they need, which then packages it.

  • drspod@lemmy.ml
    12·
    2 months ago

    From my understanding, a lot of code in the graphics drivers is special-case handling for specific games to optimize for the way that the game uses the APIs. Is this correct?

    In which case it would make sense to have the game-specific code loaded dynamically when that game is launched, since 99.99% of the game specific code will be for games that the user never runs.

    • stupidcasey@lemmy.world
      6·
      2 months ago

      From my understanding 99.999% of those “Game ready drivers” are patches for machines that you do not use but have to download anyway to keep everything on the same version.

    • SteveTech@programming.devEnglish
      3·
      2 months ago

      My understanding is that most of that all lives in mesa, and the kernel driver basically just abstracts the hardware.

  • Vik@lemmy.worldEnglish
    4·
    2 months ago

    Worth noting from the original article

    Fedora is working around this in their latest packages by beginning to probe SimpleDRM immediately. Fedora / Red Hat though isn’t the only ones using Plymouth but is largely in use by all major Linux distributions of the past decade. But in recent years the AMDGPU driver has only continued to grow much larger in supporting newer GPUs and tacking on additional features and optimizations.

  • boredsquirrel@slrpnk.net
    3·
    2 months ago

    Monolithic kernels and drivers are an issue.

    I understand why its easy, but on Fedora Atomic I even have all the userspace drivers for intel, amd, nvidia and maybe more, even though I clearly just use intel…

    • Coelacanthus@lemmy.kde.social
      5·
      2 months ago

      The problem is not caused by mono kernel. Just because AMDGPU driver was developed in mono style. i.e. they include the code of all generations in one driver. In monolithic kernel, the developer can develop drivers with “micro” style. e.g. Intel’s GPU driver doesn’t use mono style, they created a new driver when they changed GPU hardware architecture.

      Monolithic kernel is a concept about address space. If all parts of a kernel are running in the same address space, this is a monolithic kernel, otherwise it’s a micro kernel.

      This problem is about how to split parts, but not how to place parts in memory.

    • xan1242@lemmy.dbzer0.com
      5·
      2 months ago

      This is the real issue. This is one area that Windows, despite its historical hardships, handles much better.

      (Mac OS too but they killed kexts for the public anyway)

      I’d love to see a more dynamic approach (that doesn’t rely on DKMS) someday.

      • Chewy@discuss.tchncs.de
        1·
        2 months ago

        I believe the advantage is that old drivers still work as they are all in the kernel. With them sharing much code it’s not even that big of a disk space issue. Edit: A more dynamic approach would be great though, especially with this size issue popping up.

        In a way it’s great that I’m able to replace any part of my system and it just works without me having to make sure the old GPU driver doesn’t leave some traces behind–altough while writing this the latter part shouldn’t be an issue with Windows auto download and installation of drivers.