Announcement

Collapse
No announcement yet.

AMDGPU Linux 6.3 Addition To Help With Optimized Buffer Placement

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

  • AMDGPU Linux 6.3 Addition To Help With Optimized Buffer Placement

    Phoronix: AMDGPU Linux 6.3 Addition To Help With Optimized Buffer Placement

    On Friday AMD sent out another round of feature patches for new kernel graphics driver material they have readied in advance of the Linux 6.3 kernel cycle...

    https://www.phoronix.com/news/Linux-6.3-AMDGPU-New-uAPI

  • #2
    pcie gen 1 supremacy, we never needed to go higher obviously

    Comment


    • #3
      Is this implying that all of these GPUs have been running at gen 1 speeds, or just in Marek's development? In either case, it is a little alarming.

      Comment


      • #4
        Originally posted by schmidtbag View Post
        Is this implying that all of these GPUs have been running at gen 1 speeds, or just in Marek's development? In either case, it is a little alarming.
        Just Marek's system (and any others with misconfigured BIOS, etc)
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          Marek was unknowingly playing the optimization game on Hard...

          Comment


          • #6
            Originally posted by Michael View Post

            Just Marek's system (and any others with misconfigured BIOS, etc)
            Yeah. It's so common I've stopped pointing it out to people.
            Linux makes little effort to care or make it noisy.
            PCIe link training and serdes poking is usually out of the scope. "It is what it is."

            Comment


            • #7
              Whew, it's quite shocking that someone who's into optimizing gpu performance isn't able to notice such a thing easily on Linux.
              I ran with my memory clocked at 2133MHz insted of the 3600 that I hab specified in BIOS for a year (because I put in two modules per channel), but I suspected something was wrong (since booting didn't go too well for the first few attempts and each time after BIOS updates). But there seems to be no way to read current frequencies and timing for memory on Linux. Where on Windows it's easy to do with CPU-Z for example. I just found out by using an USB stick with Windows on it.

              Hardware information is just a thing where Linux is severly lacking. And reporting problems to the user is equally badly supported :-(

              Comment


              • #8
                Originally posted by mazumoto View Post
                Hardware information is just a thing where Linux is severly lacking.
                PCIe information always been available in sysfs in human readable form. E.g.,

                Code:
                cat /sys/class/pci_bus/<pci device>/device/current_link_speed
                cat /sys/class/pci_bus/<pci device>/device/current_link_width
                cat /sys/class/pci_bus/<pci device>/device/max_link_speed
                cat /sys/class/pci_bus/<pci device>/device/max_link_width

                Comment


                • #9
                  Originally posted by mazumoto View Post
                  Whew, it's quite shocking that someone who's into optimizing gpu performance isn't able to notice such a thing easily on Linux.
                  I ran with my memory clocked at 2133MHz insted of the 3600 that I hab specified in BIOS for a year (because I put in two modules per channel), but I suspected something was wrong (since booting didn't go too well for the first few attempts and each time after BIOS updates). But there seems to be no way to read current frequencies and timing for memory on Linux. Where on Windows it's easy to do with CPU-Z for example. I just found out by using an USB stick with Windows on it.

                  Hardware information is just a thing where Linux is severly lacking. And reporting problems to the user is equally badly supported :-(
                  You know that after every BIOS update the optimized defaults are loaded ?

                  And DDR4 2133mts is completly fine cause thats the standard, XMP is overclocking, even though modern RAM kits run fine on XMP, but you have to activate it manually.

                  Edit PCI 1.0 to 4.0 are official specs by the pci association and they should be trained automatically by the used device, where the slowest user suggests the max speed if you have a cpu 4.0 and gpu 4.0 it should run 4.0, if you have a chipset 3.0 and a 4.0 nvme it will run 3.0.

                  Exeptions are powermanagment features if PCIE goes into a power state it lowers the transfer rate per lane and it can go back as far as PCIE 1.1.

                  So is this post even confirmed or is it just that he reads the data at idle. I can probably post a screenshot of gpuz aswell where my rtx 30 4.0 runs at 1.1 speed.

                  IDLE
                  https://gpuz.techpowerup.com/23/01/23/d76.png

                  LOADED
                  https://gpuz.techpowerup.com/23/01/23/u6t.png
                  Last edited by erniv2; 23 January 2023, 07:22 PM.

                  Comment


                  • #10
                    Originally posted by erniv2 View Post


                    Edit PCI 1.0 to 4.0 are official specs by the pci association and they should be trained automatically by the used device, where the slowest user suggests the max speed if you have a cpu 4.0 and gpu 4.0 it should run 4.0, if you have a chipset 3.0 and a 4.0 nvme it will run 3.0.
                    Except famously for AMD Vishera CPUs which support 3.0, but only 1 motherboard* was ever made with PCIe bridge chips >2.0!

                    * SABERTOOTH 990FX/GEN3 R2.0

                    ​AMD had given up even trying with the later AMD-FX CPUs.

                    Comment

                    Working...
                    X