Announcement

Collapse
No announcement yet.

New Benchmark Test Profiles This Weekend: GIMP, Memcached, JPEG Turbo, More OpenCL

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

  • New Benchmark Test Profiles This Weekend: GIMP, Memcached, JPEG Turbo, More OpenCL

    Phoronix: New Benchmark Test Profiles This Weekend: GIMP, Memcached, JPEG Turbo, More OpenCL

    Yesterday I spent a fair amount of time updated some existing test profiles as well as pushing out some new test profiles onto OpenBenchmarking.org for use by those doing their open-source, cross-platform benchmarking with the Phoronix Test Suite...

    http://www.phoronix.com/scan.php?pag...ts-GIMP-mcperf

  • #2
    If you're benchmarking GIMP, why not benchmark its image processing core directly, namely GEGL? There is a command line binary "gegl" that performs all the same operations that GIMP would, but without GIMP UI and all the complexity associated with that. It's make for a great benchmark on a real-world workload.

    It also has OpenCL support, so it could be used to stress both CPU and GPU. There is a matrix showing the porting status of various operations on the GIMP wiki.

    Comment


    • #3
      Originally posted by Shnatsel View Post
      If you're benchmarking GIMP, why not benchmark its image processing core directly, namely GEGL? There is a command line binary "gegl" that performs all the same operations that GIMP would, but without GIMP UI and all the complexity associated with that. It's make for a great benchmark on a real-world workload.

      It also has OpenCL support, so it could be used to stress both CPU and GPU. There is a matrix showing the porting status of various operations on the GIMP wiki.
      The GIMP benchmark runs without loading the UI. If you have any documentation or scripts to show how to effectively benchmark gegl, happy though to add a test profile for it too.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        Now, let's see if the forum would allow me to post links.

        http://www.gegl.org/ - official website with source code and docs

        http://manpages.ubuntu.com/manpages/...n1/gegl.1.html - gegl command line command manpage

        http://wiki.gimp.org/wiki/Hacking:Po...ilters_to_GEGL - status matrix for porting operations to OpenCL

        Comment


        • #5
          Good news - it seems GEGL has performance testing binaries already! I'll figure out how to use them and post an update here as soon as I'm done

          Comment


          • #6
            Originally posted by Shnatsel View Post
            Good news - it seems GEGL has performance testing binaries already! I'll figure out how to use them and post an update here as soon as I'm done
            Great, thanks.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by Michael View Post

              Great, thanks.
              The folder gegl/perf contains some performance benchmarks. However is important to notice that due to the GEGL architecture the performance of these tests is sub optimal. Since for every tile (the gegl decomposes the image in tiles) is necessary to allocate and copy to the GPU. For this case what you are going to measure is basically the timing to allocate things on the GPU and to copy to it. For real use, for instance on a gimp session, the buffers pre allocated are preserved. However I believe that still necessary to copy to and from the gpu. Again interfering with the results

              Comment


              • #8
                There doesn't seem to be a way to force OpenCL usage outside of GEGL's own scripts under perf/, so I'm skipping the obvious "let's build a real pipeline and see how it performs" because I don't want to write a lot of custom code in C that I will probably get wrong in terms of performance the first couple of times.

                Fortunately, GEGL's own performance testing scripts seem to be pretty good. They don't do a lot of iterations internally (at about 16) so they show considerable variance, but that's probably for the best since PTS can measure the variance. One needs merely to build and install GEGL (or point it to its plugins folder in the build dir instead of installing it globally) and run test scripts from the perf/ directory, like this:
                Code:
                $ GEGL_USE_OPENCL=yes perf/test-bcontrast
                @ bcontrast: 655.52 megabytes/second
                @ bcontrast (OpenCL): 294.36 megabytes/second
                Sadly, with the latest 0.3.8 release if OpenCL is disabled or not available it will print CPU results as OpenCL. I have discussed this with pippin in GEGL IRC and written a patch that fixes it, which can be found here as an attachment: https://bugzilla.gnome.org/show_bug.cgi?id=777252

                With my patch applied, the output when OpenCL is disabled is the following:
                Code:
                $ GEGL_USE_OPENCL=no perf/test-blur
                @ gaussian-blur: 147.36 megabytes/second
                OpenCL is disabled. Skipping OpenCL test
                It will probably be simplest to apply the patch inside the test profile, before the build.

                Update: the patch has been merged, so you could use a git snapshot to get a working version too, but that comes with the obvious downside of it being a random development snapshot with no stabilization, and also has a more complicated build process.
                Last edited by Shnatsel; 01-14-2017, 12:20 PM.

                Comment


                • #9
                  Originally posted by defaultUser View Post

                  However is important to notice that due to the GEGL architecture the performance of these tests is sub optimal. Since for every tile (the gegl decomposes the image in tiles) is necessary to allocate and copy to the GPU. For this case what you are going to measure is basically the timing to allocate things on the GPU and to copy to it. For real use, for instance on a gimp session, the buffers pre allocated are preserved.
                  TL;DR: just use GIMP? It sure would be nice to improve the GIMP profile to a point where it would be compiled inside the test to make the results reproducible. But I'm afraid that still would not provide way to force OpenCL usage though, or even to check for it.

                  Would the "gegl" command-line program allocate buffers more optimally than tests do? Perhaps I could patch it to output whether it's using OpenCL or not when verbose output is requested.

                  Comment


                  • #10
                    Asked about this in IRC, this is the reply:

                    <pippin> [gegl command-line utility] won't [reuse buffers] - non interactive uses of GEGL do get penalized for data migration, thus such performance is also imporant (and will vary between vendors and hardware approaches)

                    Comment

                    Working...
                    X