Announcement

Collapse
No announcement yet.

AMD Quietly Working On New Linux GPU Driver Support Block By Block

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

  • #11
    Originally posted by Dukenukemx View Post
    This just means us older GPU owners, you know most people who can't afford these insane GPU prices, won't be able to use the new drivers.
    There's nothing stopping anyone from porting the old drivers to this modular architecture though?

    Comment


    • #12
      That's the right move for AMD. They need to prepare their driver earlier for Linux, so we don't end up with the situation where we have to wait one year after release to get ray tracing acceleration support, for example.

      Comment


      • #13
        Originally posted by ssokolow View Post

        How's that CUDA support going? </devils_advocate>
        How is your vendor lock-in going?

        Comment


        • #14
          Originally posted by Aeder View Post

          There's nothing stopping anyone from porting the old drivers to this modular architecture though?
          That was already largely the case for older GPUs. The driver was always structured around IP versions, but on earlier asics, the list of IPs present on an SoC was hardcoded in the driver based on the PCI IDs. So the overall structure of the driver hasn't really fundamentally changed. Now that information is available via tables on the board so the driver handling can be made more generic and there is less asic specific logic required to enumerate the IPs.

          Comment


          • #15
            Originally posted by eyesore View Post

            VRAM down clocking is there for RDNA1, and I'm quite sure it's there for RDNA2 too (but don't quote me on that). Do you perhaps use a display with a niche refresh rate like 165Hz? Higher refresh rates besides 120 and 144 (maybe 240Hz too) have non-standard timings for the most part and cause drivers to push mem clock to max in order to avoid black screen and/or crash.
            it doesn't matter. it does not down clock. but works just fine on windows since that one driver a year ago that brought frequency scaling for vram on 6xxx series. including 165hz.
            Last edited by middy; 18 February 2022, 02:40 PM.

            Comment


            • #16
              Originally posted by middy View Post
              it doesn't matter. it does not down clock. but works just fine on windows since that one driver a year ago that brought frequency scaling for vram on 6xxx series. including 165hz.
              Same goes for me except that every other RR besides the 144Hz causes VRAM to clock @ max (be that 24, 60, 120 etc.. Hz). An idiosyncrasy of my monitor model's EDID I believe. This is consistent on both Windows and Linux. Have you checked other refresh rate modes too?

              I just in case ping agd5f as he has (obviously) a lot more in-depth knowledge about the behaviour such as this and could possibly offer an explanation for this.

              EDIT: If it indeed clocks down on Windows but doesn't on Linux, then you should open a bug report (and possibly offer and recording/screenshots if they can't reproduce this on their HW and available RR modes).
              Last edited by eyesore; 18 February 2022, 03:13 PM.

              Comment


              • #17
                Originally posted by eyesore View Post

                Same goes for me except that every other RR besides the 144Hz causes VRAM to clock @ max (be that 24, 60, 120 etc.. Hz). An idiosyncrasy of my monitor model's EDID I believe. This is consistent on both Windows and Linux. Have you checked other refresh rate modes too?

                I just in case ping agd5f as he has (obviously) a lot more in-depth knowledge about the behaviour such as this and could possibly offer an explanation for this.
                See my comments here:
                Phoronix: AMD Quietly Working On New Linux GPU Driver Support Block By Block AMD's Linux graphics driver engineers have been working on the driver support for new graphics processors and now the patches are at the earliest stages of publishing. However, due to driver handling changes, it's sharply different this time around

                Comment


                • #18
                  Originally posted by Anux View Post
                  Not sure if this is the reason. Having multiple configurations of IP blocks combined and giving each a single PCI ID is a huge mess. The new approach will lead to much better/easier code reuse.
                  AFAIK we never gave each IP block its own PCI ID. The change here is going from a hard-coded list of IP blocks in the driver to using an IP discovery table from firmware. The list of IP blocks was based on PCI ID, but there was only one PCI ID per chip.
                  Last edited by bridgman; 18 February 2022, 07:43 PM.
                  Test signature

                  Comment


                  • #19
                    Originally posted by Dukenukemx View Post
                    This just means us older GPU owners, you know most people who can't afford these insane GPU prices, won't be able to use the new drivers.
                    They're not new drivers - the only change is the way we get the list of IP blocks to initialize and use.

                    If you look at the commit you can see the per-chip hard-coded lists of IP blocks that were removed:

                    https://github.com/torvalds/linux/co...b23f85bd8e09a4

                    The actual driver logic changed from per-chip to per-IP-block when we moved from radeon to amdgpu... in fact the primary reason for introducing a new driver was to build it around IP blocks from the start.
                    Last edited by bridgman; 18 February 2022, 05:14 PM.
                    Test signature

                    Comment


                    • #20
                      Originally posted by eyesore View Post

                      Same goes for me except that every other RR besides the 144Hz causes VRAM to clock @ max (be that 24, 60, 120 etc.. Hz). An idiosyncrasy of my monitor model's EDID I believe. This is consistent on both Windows and Linux. Have you checked other refresh rate modes too?

                      I just in case ping agd5f as he has (obviously) a lot more in-depth knowledge about the behaviour such as this and could possibly offer an explanation for this.

                      EDIT: If it indeed clocks down on Windows but doesn't on Linux, then you should open a bug report (and possibly offer and recording/screenshots if they can't reproduce this on their HW and available RR modes).
                      i tried 144hz, and 165hz on linux and its 100% memory speed. but, dropping to 120hz and below it is actually dropping frequency. which is new because when i got my 6900 xt, even at 60hz it ran at 100% memory speed. i am on kernel 5.16* and i got my 6900 xt when kernel 5.11 came out. i am using gnome on wayland and monitor its frequency with radeontop.

                      with windows, memory speeds drops all the way down to 14mhz with 165hz at 1440p freesync enabled and it very dynamic based on load. 1629197030638.jpg
                      Last edited by middy; 18 February 2022, 04:06 PM.

                      Comment

                      Working...
                      X