Announcement

Collapse
No announcement yet.

RadeonTop: A New Utility For Open AMD Users

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

  • RadeonTop: A New Utility For Open AMD Users

    Phoronix: RadeonTop: A New Utility For Open AMD Users

    A frequent Phoronix Forums contributor has created RadeonTop, a new utility for users of the open-source ATI/AMD Radeon Linux graphics driver...

    http://www.phoronix.com/vr.php?view=MTEzNTM

  • #2
    that is...awesome!

    Comment


    • #3
      Thanks for the plug Michael

      One correction:
      RadeonTop allows for monitoring of undocumented performance counters on Radeon graphics hardware from the R600 series and newer.
      The register is documented, the docs merely conflict each other

      Comment


      • #4
        Is this technically possible on r300 based hardware too? Since all r300 based hardware pretty much uses the open driver, this would be really nice to have there. r600 based users may still be using the blob for a while?

        Comment


        • #5
          Hmm would this be helpfull in trying to optimize the driver?

          Comment


          • #6
            The register this app queries did not exist until in r600.

            There are some more limited ones in earlier series, whether they're useful enough I don't know. I don't have much cards from r300-r500 anyway (one r500 in a laptop).

            Comment


            • #7
              this is great I was looking for something just like this, however, is there any way to get that data as a single output? I'd like to use the data from it for a graphical tool I have. Also, does anybody know how to get VRAM usage?

              Comment


              • #8
                There is a GL extension ATI_memory or something, which is unsupported by mesa

                As for the dumping, Michael requested that too. How would you like the interface?

                Comment


                • #9
                  Originally posted by curaga View Post
                  There is a GL extension ATI_memory or something, which is unsupported by mesa

                  As for the dumping, Michael requested that too. How would you like the interface?
                  how would I get the ATI_memory information from a CLI? I personally would prefer the interface to work much like how the nvidia-smi or the aticonfig outputs, where you enter the command and it outputs the results once as plain text. That way it's easy to implement into other programs.

                  Comment


                  • #10
                    how would I get the ATI_memory information from a CLI?
                    You'd write an app that calls the GL extension. But it would currently only work on fglrx.

                    where you enter the command and it outputs the results once as plain text.
                    I mainly mean the text file behavior:

                    - output one line once, containing the percentages about the last second (= one sec delay as data is gathered)
                    - output one line once, containing a 1 for each unit that is busy at that moment

                    If you want the second, the execution overhead becomes big (~17ms), so you can't have really accurate results - getting say 1000 ticks per sec becomes impossible.

                    Alternatively, it could output either of those until terminated. Percentages once per second, or direct values once per tick. Optionally with a timeout or a max number of lines.

                    Comment


                    • #11
                      I mainly mean the text file behavior:

                      - output one line once, containing the percentages about the last second (= one sec delay as data is gathered)
                      - output one line once, containing a 1 for each unit that is busy at that moment
                      I would probably guess that you'd just copy the behavior of iostat and vmstat so that it's a familiar behavior for people.

                      So you would just output a line of data after the prescribed time period and have the position of the data be significant. Effectively a space deliminated output.

                      If you want the second, the execution overhead becomes big (~17ms), so you can't have really accurate results - getting say 1000 ticks per sec becomes impossible.
                      Just have the default something that makes sense and let users optionally specify time periods. Limitations on time periods required to get meaningful results should be specified in documentation. See the man files for those above mentioned programs and see if that could be meaningfully applied to what you are doing.

                      For example; if I am running a series of compute nodes in a cluster I probably am not going to want to have per-second resolution. More then likely I would like a report every five minutes or so. Anything shorter of that you start running into issues with network overhead and nagios overhead and whatnot when dealing with dozens or hundreds of systems. So it would run once every 5 minutes and gather statistics for 20 seconds. Typically 30 seconds is the time out for programs like Nagios so I wouldn't want to gather stats for longer then that. Or possibly have a running program that monitors constantly and then queries that daemon for reports every five minutes. Something like that if you can imagine it.

                      Alternatively, it could output either of those until terminated. Percentages once per second, or direct values once per tick. Optionally with a timeout or a max number of lines.
                      You could also throw load averages into the mix. 1 minute, 5 minutes, 15 minute averages similar to how 'uptime' load works.

                      I don't know the nature of the registers to give more specific information then that, unfortunately.

                      Comment


                      • #12
                        Geeky

                        Sounds geeky.

                        Hope someone makes something similar for Intel and Nvidia too.

                        Comment


                        • #13
                          So you would just output a line of data after the prescribed time period and have the position of the data be significant. Effectively a space deliminated output.
                          That wouldn't make sense, since the fields differ a bit between cards. Harder to parse, even with a header line. Also I want to keep the freedom to reorder the output if needed if some field proves wrong, etc.

                          I'm leaning towards continous output of percentages, ie timestamped lines with each field specified with a couple letters.

                          11234324: vgt: 50%, foo: 70%

                          Comment


                          • #14
                            Originally posted by uid313 View Post
                            Sounds geeky.

                            Hope someone makes something similar for Intel and Nvidia too.
                            http://cgit.freedesktop.org/xorg/app...ntel_gpu_top.c

                            Comment


                            • #15
                              Originally posted by oliver View Post
                              Is this technically possible on r300 based hardware too? Since all r300 based hardware pretty much uses the open driver, this would be really nice to have there. r600 based users may still be using the blob for a while?
                              Older asics have similar registers (RBBM_STATUS, etc.) that can be polled the same way.

                              Comment

                              Working...
                              X