Announcement

Collapse
No announcement yet.

Linux 6.2 Lands S0ix Idle Change For AMD Ryzen "Rembrandt" Laptops & Newer

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

  • Linux 6.2 Lands S0ix Idle Change For AMD Ryzen "Rembrandt" Laptops & Newer

    Phoronix: Linux 6.2 Lands S0ix Idle Change For AMD Ryzen "Rembrandt" Laptops & Newer

    A change was merged this holiday weekend ahead of Linux 6.2-rc2 that adjusts the default behavior for AMD Ryzen 6000 series "Rembrandt" laptops and newer...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Do you know how to stay with AMD GUID? I have (will have soon again) a 845 G9.

    BTW. i can run some benchmarks on Fedora 37 if you are interested in.

    Comment


    • #3
      I'm not sure "wrong" applies here. It might be wrong from AMD's perspective in that they'd prefer to have OEMs use their GUIDs instead of Microsoft's. However, from the OEM perspective, as the contributor points out, using the AMD GUIDs is extra work for their ACPI/firmware teams. The OEMs explicitly state they only support Microsoft Windows on these products so it doesn't matter (to them) if Linux, BSD, etc has problems with requiring the MS GUIDs to efficiently utilize the hardware. AMD isn't going to win that game. If the OEMs wanted to directly support alternative OSes then they'd create models that specifically do so with ACPI tables that aren't full of Microsoft-isms.

      Comment


      • #4
        Microsoft loves linux, yeah right! This seems like a cop out of AMD forcing proper firmware instead of just taking the easy way out and using the Windows route.

        Comment


        • #5
          Originally posted by kylew77 View Post
          Microsoft loves linux, yeah right! This seems like a cop out of AMD forcing proper firmware instead of just taking the easy way out and using the Windows route.
          i don't like microsoft either, but at least if all the vendors actually adopt microsoft way, linux side of things can then just build off of that. in a way, it helps create a standard to build off of instead of having 784237489237489 different ways. acpi has always been an absolute minefield of a mess from vendors not keeping to spec.

          Comment


          • #6
            Originally posted by stormcrow View Post
            I'm not sure "wrong" applies here. It might be wrong from AMD's perspective in that they'd prefer to have OEMs use their GUIDs instead of Microsoft's. However, from the OEM perspective, as the contributor points out, using the AMD GUIDs is extra work for their ACPI/firmware teams. The OEMs explicitly state they only support Microsoft Windows on these products so it doesn't matter (to them) if Linux, BSD, etc has problems with requiring the MS GUIDs to efficiently utilize the hardware. AMD isn't going to win that game. If the OEMs wanted to directly support alternative OSes then they'd create models that specifically do so with ACPI tables that aren't full of Microsoft-isms.
            I think this is only part of the story. Its in Microsoft's best interest to have Windows working, so I wouldn't be surprised if those "Microsoft"ism's are a result of Microsoft being fed of OEM's not doing things properly and they are like "we have had enough, we are going to fix it ourselves". ACPI may have also contributed to the situation (iirc Linus is not a fan of ACPI, I remember his saying it was made by braindead monkeys or something along those lines).

            Its the same deal with S3 sleep vs S0 sleep. S3 is the traditional sleep that Linux was typically built for, but it requires having correct firmware from the OEM to work well. On the other hand S0 is all driven from the kernel/OS and Microsoft has been heavily pushing for S0 on all modern devices. Granted Windows is currently having teething issues getting S0 to work properly (Linus Tech Tips did a great video on this, as well as an official response from Microsoft as to why its hard to solve these teething issues, tl;dr they have heisenbug problems because if they turn on telemetry to diagnose the problems it alters the behaviour of the OS and they no longer get the bug), but once those are fixed the sleep should become much more reliable and most importantly Microsoft is not reliant on well functioning firmware (which if anyone has any idea how much cheap/unreliable/out of spec hardware is out there, this isn't too surprising).

            Comment


            • #7
              The fun part is that ACPI was designed to be OS-independent; AFAICT it works literally by firmware sending the OS scripts (in a dedicated bytecode) which it should execute to achieve certain actions, like sleep. It is insane (or EEE) that we somehow ended up with parallel "Microsoft mode" of doing this that is also the only one working.

              Comment


              • #8
                I think it all goes back to the beginning when IBM made the decision to outsource the OS for the original "IBM" personal computer to Microsoft. Without an OS you have a doorstop for a personal computer. And then when IBM let anyone make an IBM "compatible" pc with any parts you could find at the cheapest "BOM" possible (Billable Order of Materials) then eventually things like ACPI tables and BIOS settings became a mess of vendor $uckery unless everyone pretty much standardized to Microsoft's way since...after all...from the beginning in 1981 Microsoft has supplied the OS for the "Personal Computer". Of course this doesn't happen with Apple since they make it all, hardware, software, OS, firmware, kernel, etc....Not saying this as a fanbois or in snark. Just for compare and contrast purposes.

                Comment

                Working...
                X