Announcement

Collapse
No announcement yet.

Announcing radeontop, a tool for viewing the GPU usage

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

  • #46
    Thanks. Please use the github interface in the future, forums tend to mangle patches.

    Field width is changed, the lerp averages added on todo.

    Comment


    • #47
      0.6 released with dumping support.

      Comment


      • #48
        Great tool!
        Even if it just shows how much the CPU limits the driver. Example: I can run 2 instances of minecraft with max graphic settings and none of the values in radeontop goes near 100% while the GPU is in the low PM profile. Of course the FPS is bad and the CPU is at 100% (yes, I know, minecraft isn't the best here cause it eats up much CPU by default, but anyway...).

        Michael should include radeontop measuring in his benchmarks.

        Comment


        • #49
          Thankyou for this tool! Finally I can judge how powerful my graphics card is VS how well the libre driver can push it.

          In my ignorance, I was wondering if I could take the top 'Graphics pipe' value to be the best 'single number' to represent GPU usage? If yes I think I need to work this into my conky configuration.

          Comment


          • #50
            Yes, you can use that value as a "general GPU utilization" one. If it's less than 100%, you are cpu-bound.

            Comment


            • #51
              Thank you Its very enlightening - 15-25% usage on a 1080p h.264 encode, minetest takes 30-40%, FreeDoom 20-30%, idle desktop with 2* 1920x1200 0-3%, with a Radeon 4870 graphics card - i.e. nowhere near using the card, yet in minetest's case things are considered 'GPU limited'.

              Just yesterday I got kernel v3.9 with Debian Testing, I guess when Mesa goes to v9.2 I can finally move from Open GL 2.1 -> 3.1 or 3.3. Will be very interesting to see if minetest fps goes up, I can finally use the best VPU plugin with pcsx2, and what radeontop says about all this.

              Comment


              • #52
                Finally got round to making a script to output the GPU info somewhere useful then conky can read it in (intended to be ran as root, via an init.d script):

                Code:
                #!/bin/bash
                
                
                # Make sure the directory structure is in place
                [[ ! -d '/run/shm/radeontop' ]] && mkdir -p '/run/shm/radeontop'
                
                # Removing old data
                rm '/run/shm/radeontop/gpu' 2>/dev/null
                
                while true
                do
                    # Running radeontop in dump mode, killing off the silly full buffering and outputting just the GPU stats. AWK's redirection fails - you must close the file to have it behave like a bash overwrite, and if you don't close or don't insert an arbitrary delay prior to the print (e.g. system sleep/beep call), nothing is output!
                    stdbuf -oL radeontop -d - | awk '($2 == "gpu") { print substr($3, 1, length($3) - 1) > "/run/shm/radeontop/gpu"; close("/run/shm/radeontop/gpu"); }'
                done
                Had great difficulty getting AWK to do its job - looks like some strange buffering is happening if you don't close the file and don't arbitrarily delay the command.

                Comment


                • #53
                  Apparently it's been ported to OpenBSD with no code changes. Nice to know, I wasn't expecting that.

                  Now, anyone running the AMD blob (on Linux) willing to try it? I wonder if it also works with the blob. If so, the case for PTS integration would be clear - "is it cpu or gpu limited" result for every AMD graphics test

                  Comment


                  • #54
                    Rejoice, for a new release is available! From Russia with love.

                    v0.7
                    This release comes with many locale fixes and a complete Russian
                    translation.

                    The pci ids were updated to detect Oland, Hainan, Bonaire, Kabini, and
                    Kaveri. Dumping works better in pipes.

                    Comment


                    • #55
                      Are there any plans to report on the VRAM usage? I've just discovered the gallium_hud functionality in mesa, and appreciated the VRAM graph there.

                      Comment


                      • #56
                        I don't think that information is available via a register. Only the memory manager knows how much is used, and it currently only exports that information in debugfs.

                        Comment


                        • #57
                          Cheers - I'll look into that.

                          Comment


                          • #58
                            wow!! great reply. really interesting. Cheers!!

                            Comment


                            • #59
                              Faithful followers, Dear Leader of Best Korea announced a new version is available on a repository near you.
                              v0.8

                              Release highlights include VRAM reporting on a 3.15 kernel or newer, as well as pci ids for Hawaii.
                              I might have just accidentally killed OpenBSD support, not sure if libdrm is available there. If not, patches welcome OpenBSD users, should be fairly easy to ifdef out.

                              In other news, PTS has radeontop support in its git version now, to be released as 5.1 or 5.0.2 I believe. So if you install radeontop as suid root, you get GPU usage graphing:
                              MONITOR=gpu.usage phoronix-test-suite run pts/blahblah

                              Comment


                              • #60
                                It doesn't work on Bonaire. Everything is at 0%, only VRAM seems to be correct.

                                Comment

                                Working...
                                X