Announcement

Collapse
No announcement yet.

OpenCL Is Coming To The GIMP Via GEGL

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

  • OpenCL Is Coming To The GIMP Via GEGL

    Phoronix: OpenCL Is Coming To The GIMP Via GEGL

    Outside of the direct X.Org / Mesa / Linux work being done this year as part of Google's Summer of Code, one of the more interesting projects is work by a student developer with GIMP who is bringing OpenCL support to the graphics program's GEGL image library...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by Qaridarium
    this means if you have a realy fast cpu the cpu will be faster without the GPU!
    If one uses PBOs instead of buffer arrays then it should be faster and/or more energy effective because you don't have to transfer data back and forth.
    Also, upgrading the GPU also improves performance, when I upgraded from 9600gt to gtx 560Ti the PBO read/write performance in my little test went up like 4 times!

    So it's really mostly up to the quality of the source code and the solutions it uses.
    Even if both the CPU and GPU solutions run equally fast (that is you have a newer CPU and older GPU) you should still use the GPU solution because it saves energy by doing less I/O.

    But then there's still some folks with old hw that doesn't support PBOs yet (though it's a shame nowadays to not support PBOs) and some crappy drivers maybe.

    Comment


    • #3
      Originally posted by Qaridarium
      this means if you have a realy fast cpu the cpu will be faster without the GPU!

      only because "Most of the 483 milliseconds was spent transferring data to/from the GPU memory"
      The idea is to copy the data once, to a let a whole lot of filters do their thing and only then copy back. The copying back and forth to the GPU will always be the bottleneck. This benchmark gives the worst case scenario.

      Comment


      • #4
        Blah blah blah... but what about 16bit/channel?
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #5
          Originally posted by darkbasic View Post
          Blah blah blah... but what about 16bit/channel?
          High bit depth will be in 3.0. It's been the plan for quite a while already.

          Comment


          • #6
            This will be highly useful for all filters/plugins.

            It should also be theoretically possible to cut the transfer time in half, keeping the working copy of the graphics on the card at all times, just sending updates on the merged graphics.
            Even for just a simple brush stroke, it will typically be applied on just one layer, and the visible image requires a fair amount of computations on top, which can then be copied back.

            Comment


            • #7
              Originally posted by darkbasic View Post
              Blah blah blah... but what about 16bit/channel?
              GeGL has had 16bit or greater per channel since the beginning. Are you perhaps talking about the Gimp?
              In which case the answer is when all the internals are replaced with GeGL.

              Comment


              • #8
                Originally posted by Qaridarium
                this means if you have a realy fast cpu the cpu will be faster without the GPU!

                only because "Most of the 483 milliseconds was spent transferring data to/from the GPU memory"
                Only until Fusion is common Then moving data from cpu to gpu is a zero-copy operation. Perhaps it already is on Sandy (/Ivy for OpenCL) too?

                Comment


                • #9
                  Originally posted by curaga View Post
                  Only until Fusion is common Then moving data from cpu to gpu is a zero-copy operation. Perhaps it already is on Sandy (/Ivy for OpenCL) too?
                  Since they share both memory and an L3 cache I'd assume so...actually, I'm not sure if there would be a copy from the dedicated SB memory or not (though I know they share the same physical memory unlilke the AMD's integrated memory which had the optional sideboard).

                  Comment


                  • #10
                    from the article:

                    Of course, the big problem is that the open-source Linux graphics drivers don't yet support OpenCL. There's work in this direction over Gallium3D via another Google Summer of Code project, but it's not yet ready for end-users nor will it likely be anytime soon.

                    Denis who works on Clover wrote yesterday in his blog that things are almost done. However i have no idea when it will be merge ready.

                    Comment

                    Working...
                    X