Announcement

Collapse
No announcement yet.

MATISK: Benchmarking 1,000+ Revisions Of Mesa

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

  • MATISK: Benchmarking 1,000+ Revisions Of Mesa

    Phoronix: MATISK: Benchmarking 1,000+ Revisions Of Mesa

    With Phoronix Test Suite 3.4-Lillesand and the new MATISK support, over one thousand revisions of the Mesa graphics library were benchmarked. Two small performance optimizations were also noted.

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

  • #2
    At first I thought they were two regressions. Why the inverted time axis?

    Comment


    • #3
      Yes, all the other graphs over time go from left to right. It's confusing to suddenly have graphs doing the reverse, especially when you can't look at the commit ids to see which direction they are going in.

      As far as visualizing them better somehow - perhaps there is some way to highlight just the significant changes. Hiding any revisions with < 5% change from the previous one, perhaps? That might have to be configurable based on the test. But then you could just have a starting + ending values, and the 4 commits that surround the 2 changes instead of all 1000 runs displayed.

      Another idea: if you take a look at http://www.arewefastyet.com, their graphs give popups when you mouse over each commit. The popup includes the date and link to the code revision, as well as summarizing the change from the previous test entry. This might be tough to do in a generic fashion, but it's pretty useful IMO.
      Last edited by smitty3268; 08-01-2011, 04:55 AM.

      Comment


      • #4
        I just downloaded the latest milestone to check, but I don't get it.

        Code:
        $ ./phoronix-test-suite matisk.help
        
        User commands for the matisk module:
        
        - matisk.run-matisk
        - matisk.template
        This isn't very helpful. Questions that come to mind are:

        - When my tests require reboots (like your mesa tests), how is this handled? I.e. how do you make sure phoronix-test-suite is run again after the the reboot?
        - Do I put the reboot in the pre-install or pre-run script?
        - Doesn't the whole reboot stuff require root access? Should I run phoronix-test-suite as root for this to work?

        In general, I think a full example of how you did the mesa tests would be extremely helpful.

        Thanks,

        Erwin

        Comment


        • #5
          Just the way I happened to load the lists of contexts... and didn't reverse it afterwards.
          Originally posted by curaga View Post
          At first I thought they were two regressions. Why the inverted time axis?
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            Originally posted by ErwinJunge View Post
            I just downloaded the latest milestone to check, but I don't get it.

            Code:
            $ ./phoronix-test-suite matisk.help
            
            User commands for the matisk module:
            
            - matisk.run-matisk
            - matisk.template
            This isn't very helpful. Questions that come to mind are:

            - When my tests require reboots (like your mesa tests), how is this handled? I.e. how do you make sure phoronix-test-suite is run again after the the reboot?
            - Do I put the reboot in the pre-install or pre-run script?
            - Doesn't the whole reboot stuff require root access? Should I run phoronix-test-suite as root for this to work?

            In general, I think a full example of how you did the mesa tests would be extremely helpful.

            Thanks,

            Erwin
            - The PTS launcher is placed automatically in the user's local XDG autostart directory. When testing is done, it removes itself. So it assumes right now that you have the user set to be automatically logged in. I haven't bothered trying any GDM/KDM integration to automatically setup the auto-login on a temporary basis.

            - You can set reboot wherever you want.

            - Depending upon your permissions for reboot. You can run it as user or root, all depends upon how you have your system configured.

            Can probably post the complete Mesa scripts when I am back to the US.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by Michael View Post
              - The PTS launcher is placed automatically in the user's local XDG autostart directory. When testing is done, it removes itself. So it assumes right now that you have the user set to be automatically logged in. I haven't bothered trying any GDM/KDM integration to automatically setup the auto-login on a temporary basis.

              - You can set reboot wherever you want.

              - Depending upon your permissions for reboot. You can run it as user or root, all depends upon how you have your system configured.

              Can probably post the complete Mesa scripts when I am back to the US.
              Thanks for the quick reply, looking forward to working with this.

              Comment


              • #8
                So the reboot functionality depends on either gnome or kde? I don't think any other DE implements that autostart dir, though maybe e17 does.

                Comment


                • #9
                  Originally posted by curaga View Post
                  So the reboot functionality depends on either gnome or kde? I don't think any other DE implements that autostart dir, though maybe e17 does.
                  Do you have a better recommendation?

                  I am always testing from GNOME and most of the enterprise clients I care about are using GNOME or KDE, so for 96% (sans those not running a DE) of the important instances the XDG autostart should work fine.
                  Michael Larabel
                  http://www.michaellarabel.com/

                  Comment


                  • #10
                    Just documenting what to call manually in .xinitrc or similar would be fine.

                    Comment

                    Working...
                    X