Announcement

Collapse
No announcement yet.

radeon-profile: tool for changing profiles and monitoring some GPU parameters

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

  • #46
    Originally posted by marazmista View Post
    Thanks ChrisXY and asdfblah for yours posts which gave me an idea how to impelment multi gpu! It is initial (probably graphs will be buggy), but maybe will work. Also I updated temperature readings. If there is a hwmon device for card(which I think is when card is connected though PCI), app try to read temps from sysfs, so there is no need for lm_sensors.
    Ok, I have looked a little bit at the code, but as I see it your gpu detection is still botched.


    All in radeon_profile.cpp:
    In radeon_profile::detectCards() you figure out all the */cardX/* paths and put them in an array.
    But what you actually write in the combobox is "cardY" where Y is the index in that array. What you should write in that combobox is the X from */cardX/* (either that, or you do it more differently)

    Because in radeon_profile::figureOutGPUDataPaths() you use ui->combo_gpus->currentIndex() to get a gpuIndex that you insert into the paths like "/sys/class/drm/card"+gpuIndex+"/device/power_method". But what you are getting now is the index of the selected element in the combobox.

    That may have a chance of working with two radeon cards, but remember that you only put cards with DRIVER=radeon at the first place in the combobox. My card0 is actually an intel gpu and is not put in the combobox. My card1 is radeon, which is put into the combobox, but being the only element in the combobox it has index 0.

    My c++ isn't very strong and I didn't want to spend too much time at it for now, so I just hardcoded QString gpuIndex = "1" in radeon_profile::figureOutGPUDataPaths().

    It at least does show something in the GPU data text window but the whole gui is very sluggish and "hangy" and the content vanishes for seconds before being refreshed. Maybe you need to put some stuff for reading the values from the kernel in another thread.

    Comment


    • #47
      Stuff like that... with length-1 it will obviously only work for single digit number of cards. Well.
      Code:
      diff --git a/radeon-profile/radeon_profile.cpp b/radeon-profile/radeon_profile.cpp
      index dcc0408..9ec8430 100644
      --- a/radeon-profile/radeon_profile.cpp
      +++ b/radeon-profile/radeon_profile.cpp
      @@ -151,6 +151,13 @@ void radeon_profile::timerEvent() {
       // === Run commands to read sysinfo
       QStringList radeon_profile::grabSystemInfo(const QString cmd) {
           QProcess *p = new QProcess();
      +
      +    //TODO
      +    // is empty string when it is first called with ls /sys/class etc., but doesn't matter, later it's correct
      +    QString gpuIndex = QString(ui->combo_gpus->currentText()); // is this even the correct number to use?
      +    // doesn't seem to work anyway
      +    p->processEnvironment().insert("DRI_PRIME", gpuIndex);
      +
           p->setProcessChannelMode(QProcess::MergedChannels);
       
           p->start(cmd,QIODevice::ReadOnly);
      @@ -270,13 +277,13 @@ void radeon_profile::detectCards() {
               QFile f("/sys/class/drm/"+out[i]+"/device/uevent");
               if (f.open(QIODevice::ReadOnly)) {
                   if (f.readLine(50).contains("DRIVER=radeon"))
      -                ui->combo_gpus->addItem("card"+QString().setNum(i));
      +                ui->combo_gpus->addItem(QString(out[i][out[i].length()-1]));
               }
           }
       }
       
       void radeon_profile::figureOutGPUDataPaths() {
      -    QString gpuIndex = QString().setNum(ui->combo_gpus->currentIndex());
      +    QString gpuIndex = QString(ui->combo_gpus->itemText(0)); //initially, use first card in list
       
           powerMethodFilePath = "/sys/class/drm/card"+gpuIndex+"/device/power_method",
           profilePath = "/sys/class/drm/card"+gpuIndex+"/device/power_profile",

      Comment


      • #48
        Originally posted by TAXI View Post
        I'm using a HD 6950 also with glamor. But not with everything from git and without LLVM in the mix (LLVM seems to have some issues with cayman). I'm also using xfce, but with its build-in compositor. Now when I look into radeon-profile and monitor the GPU clock it's low when I drag around windows like crazy (3d stuff cause of compositing) but when I scroll in firefox or thunar or even when I just return thunar from minimize the GPU clock speed rises to its maximum. Now I think (correct me if I'm wrong) that both, firefox and thunar, use 2D paths for their internal rendering.
        I use the clearlooks-phenix theme (mainly because it supports both gtk2 and 3). Thunar scrolling is fine, scrolling in Seamonkey (uses the Firefox engine) on pages like www.realitatea.net (full of pictures and quite heavy) initially i have a jump for a second or so (i have 2 sec polling) to the middle level but then its back to normal no matter how i scroll the page.
        Maybe it has to do with texture loading or something.
        Also - glamor uses opengl to render everything - it converts plain 2d to opengl textures - so it does use the gpu regardless of the applications that are displayed.
        - I have the compton compositor running that uses glx as backend. It doesnt cause tearing when moving windows around, playback nor in 3d games (may be somewhat lower framerates, but nothing very visible).
        - The xfce software compositing is software only and uses more cpu (before being rendered to opengl by glamor it does its stuff exclusively via cpu processing) + introduces tearing in 3d opengl apps and sometimes in video playback too.
        - i have llvm compiled but i have R600_LLVM=0 in the /etc/environment file so it should be disabled (although some apps seem to still use it unless i explicitly tell them R600_LLVM=0). Anyway, with llvm disabled certain games run better, even webgl rendering is better. I compiled it mainly because its needed for opencl and because the challenge.

        Comment


        • #49
          Just a suggestion: use radeontop's dump mode instead of reimplementing the code.

          popen("radeontop -d -", "r") to open a pipe, then update your graph when a new line of info comes in.

          Comment


          • #50
            Originally posted by ChrisXY View Post
            Ok, I have looked a little bit at the code, but as I see it your gpu detection is still botched.


            All in radeon_profile.cpp:
            In radeon_profile::detectCards() you figure out all the */cardX/* paths and put them in an array.
            But what you actually write in the combobox is "cardY" where Y is the index in that array. What you should write in that combobox is the X from */cardX/* (either that, or you do it more differently)

            Because in radeon_profile::figureOutGPUDataPaths() you use ui->combo_gpus->currentIndex() to get a gpuIndex that you insert into the paths like "/sys/class/drm/card"+gpuIndex+"/device/power_method". But what you are getting now is the index of the selected element in the combobox.

            That may have a chance of working with two radeon cards, but remember that you only put cards with DRIVER=radeon at the first place in the combobox. My card0 is actually an intel gpu and is not put in the combobox. My card1 is radeon, which is put into the combobox, but being the only element in the combobox it has index 0.

            My c++ isn't very strong and I didn't want to spend too much time at it for now, so I just hardcoded QString gpuIndex = "1" in radeon_profile::figureOutGPUDataPaths().

            It at least does show something in the GPU data text window but the whole gui is very sluggish and "hangy" and the content vanishes for seconds before being refreshed. Maybe you need to put some stuff for reading the values from the kernel in another thread.
            Thanks, on my computer I always see "card0" so this mislead me, I realized that this morning.
            I pushed some changes to detect card correctly, but the lag is unresolved for now.

            Originally posted by curaga View Post
            Just a suggestion: use radeontop's dump mode instead of reimplementing the code.

            popen("radeontop -d -", "r") to open a pipe, then update your graph when a new line of info comes in.
            Yea, I think it will be implemented this way, thanks for suggestion.

            Comment


            • #51
              marazmista You accepted my (V10lator) first pull request.

              BTW: I have some new ideas:
              • Restructure the codes into more files, this may get big and hard to follow.
              • Ask for the root passwort at start (if not already root) (important if you want to maniulate the .drirc file of the user later, for example).
              For the second one I think some trick from TrueCrypt could work: Implement a CLI and/or daemon mode and use that with sudo. I got this from here: http://www.linux-forum.de/70118-post14.html - Another way might be to use POSIX capabilities ( http://linux.die.net/man/7/capabilities ) but I'm unsure about that. Maybe there's also a completely other way like creating a new thread with root rights (not sure if possible) and fetching the infos from there.

              Comment


              • #52
                Originally posted by TAXI View Post
                [*]Ask for the root passwort at start (if not already root) (important if you want to maniulate the .drirc file of the user later, for example).
                Is that really necessary? Every user has its own ~/.drirc file.

                Comment


                • #53
                  Originally posted by gradinaruvasile View Post
                  Is that really necessary? Every user has its own ~/.drirc file.
                  Right now radeon-profile requires root rights for most of its actions. So it would modify /root/.drirc (or, as another example, itselfs config). So yes, I think it may be necessary for multi-user systems in a foreseeable future.
                  Last edited by V10lator; 12-07-2013, 08:19 AM.

                  Comment


                  • #54
                    Updates for today:
                    • configuration
                    • monitor name/vendor in connectors list (thanks TAXI!)
                    Originally posted by TAXI View Post
                    Restructure the codes into more files, this may get big and hard to follow.
                    Yes, I will do that in near future, code is coming up to 1k lines.

                    Originally posted by TAXI View Post
                    Implement a CLI and/or daemon mode and use that with sudo.
                    I think Radeon-tray works this way.

                    Comment


                    • #55
                      Originally posted by marazmista View Post
                      Updates for today:



                      I think Radeon-tray works this way.
                      Owo, here I was browsing a thread that interests me and someone talks about my little program. =-)

                      How awesome is that?

                      I'll be sure to try your program after this.

                      Comment


                      • #56
                        yeah awesome

                        How about throwing your workforce together and making one program that can do it all?

                        I do not know however how much your programs overlap or if the code is compatible in anyway - its just a spontanious thought...

                        Comment


                        • #57
                          Originally posted by tomtomme View Post
                          yeah awesome

                          How about throwing your workforce together and making one program that can do it all?

                          I do not know however how much your programs overlap or if the code is compatible in anyway - its just a spontanious thought...
                          I would normally be all over that. But Radeon-tray is a python program while radeon-profile is C++.
                          I have never touched any C like languages, so as much as I would like to help, it's kind of out of my league.
                          We can, of course, learn from each other's programs, which is kind of what we are doing. =-)

                          Comment


                          • #58
                            Originally posted by ChrisXY View Post
                            It at least does show something in the GPU data text window but the whole gui is very sluggish and "hangy" and the content vanishes for seconds before being refreshed. Maybe you need to put some stuff for reading the values from the kernel in another thread.
                            Wow, much better now. Very good!

                            Now the only thing left to fix is that the glxinfo thingy runs for the intel gpu.
                            I'm not sure how to correctly find out which providers are configured at the moment...
                            But at least you can find all the indexes for the usage of DRI_PRIME of radeon gpus with
                            Code:
                            xrandr --listproviders | grep radeon | cut -f 2 -d " " | grep -o "[0-9]+"
                            Or better, of course, calling the randr apis directly, which might also provide some functionality to find out about the current setup...

                            Comment


                            • #59
                              Originally posted by ChrisXY View Post
                              Wow, much better now. Very good!

                              Now the only thing left to fix is that the glxinfo thingy runs for the intel gpu.
                              I'm not sure how to correctly find out which providers are configured at the moment...
                              But at least you can find all the indexes for the usage of DRI_PRIME of radeon gpus with
                              Code:
                              xrandr --listproviders | grep radeon | cut -f 2 -d " " | grep -o "[0-9]+"
                              Or better, of course, calling the randr apis directly, which might also provide some functionality to find out about the current setup...
                              Hmm... correct me if I'm wrong. When you type 'glxinfo | grep OpenGL' you see info about opengl capabilities of intel or radeon card, card selected by DRI_PRIME, or both? I don't know how to approach this problem.
                              From lspci it should get radeon card, because app filter output by "Radeon" (when you pointed this problem some time ago, the filter was just "VGA").

                              Originally posted by Stunts View Post
                              I would normally be all over that. But Radeon-tray is a python program while radeon-profile is C++.
                              I have never touched any C like languages, so as much as I would like to help, it's kind of out of my league.
                              We can, of course, learn from each other's programs, which is kind of what we are doing. =-)
                              C++ is not hard to learn for basic programming, and Qt has very good documentation for its c++ classes. But yeah, c++ is nothing like Python.

                              Comment


                              • #60
                                Originally posted by marazmista View Post
                                Hmm... correct me if I'm wrong. When you type 'glxinfo | grep OpenGL' you see info about opengl capabilities of intel or radeon card, card selected by DRI_PRIME, or both? I don't know how to approach this problem.
                                From lspci it should get radeon card, because app filter output by "Radeon" (when you pointed this problem some time ago, the filter was just "VGA").
                                Code:
                                $ glxinfo | grep OpenGL
                                OpenGL vendor string: Intel Open Source Technology Center
                                OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
                                OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0-devel (git-f9cfe5c)
                                OpenGL core profile shading language version string: 3.30
                                OpenGL core profile context flags: (none)
                                OpenGL core profile profile mask: core profile
                                OpenGL core profile extensions:
                                OpenGL version string: 3.0 Mesa 10.1.0-devel (git-f9cfe5c)
                                OpenGL shading language version string: 1.30
                                OpenGL context flags: (none)
                                OpenGL extensions:
                                $ DRI_PRIME=1 glxinfo | grep OpenGL
                                OpenGL vendor string: X.Org
                                OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
                                OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.1.0-devel (git-f9cfe5c)
                                OpenGL core profile shading language version string: 1.40
                                OpenGL core profile context flags: (none)
                                OpenGL core profile extensions:
                                OpenGL version string: 3.0 Mesa 10.1.0-devel (git-f9cfe5c)
                                OpenGL shading language version string: 1.30
                                OpenGL context flags: (none)
                                OpenGL extensions:
                                If you look at http://phoronix.com/forums/showthrea...446#post378446
                                I tried to insert the DRI_PRIME variable into the environment of external processes, but it didn't work....

                                Comment

                                Working...
                                X