Announcement

Collapse
No announcement yet.

OpenCL Is Coming To The GIMP Via GEGL

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

  • #16
    Originally posted by devius View Post
    3.0 should be a massive improvement over the current situation if they manage to pull it all off, and launch it sometime in the next 10 years. Hopefully long before the decade is over :P Two features I miss in GIMP are 16bit/channel and Free Transform. Apart from that it's an excellent program. Even with the multi-window window mode. The single window mode somehow feels more awkward than the classic gimp mode. Oh, and what the hell are they thinking with that Export instead of Save for every single image format except .xcf???

    @cl333r Are you the one working on that OpenCL backend for GEGL? If you are nice work Gimp really needs a performance boost like that.
    no, it's me. thanks
    I'm happy to answer any questions about the project.

    Comment


    • #17
      Originally posted by yogi_berra View Post
      Just think, its only been 11 years since the functionality was handed to them on a silver platter and they rejected it unanimously in favor of vapor ware.
      The people who actually patched GIMP to make FilmGIMP which later became Cinepaint were the very same people who later started GEGL to do everything properly (i.e. not like in FilmGIMP/Cinepaint). But sure, you know better about silver plates and whatnot. Facts are soooo boring, aren't they?
      Last edited by prokoudine; 08-16-2011, 09:54 PM.

      Comment


      • #18
        Originally posted by devius View Post
        3.0 should be a massive improvement over the current situation if they manage to pull it all off, and launch it sometime in the next 10 years. Hopefully long before the decade is over :P Two features I miss in GIMP are 16bit/channel and Free Transform. Apart from that it's an excellent program. Even with the multi-window window mode. The single window mode somehow feels more awkward than the classic gimp mode. Oh, and what the hell are they thinking with that Export instead of Save for every single image format except .xcf???

        @cl333r Are you the one working on that OpenCL backend for GEGL? If you are nice work Gimp really needs a performance boost like that.
        I like the separate save/export workflow - It means that I never loose layers etc because I accidently saved in the wrong format. I use gimp for texturing which means I am constantly updating a png (or dds) image to make changes in (say blender) if I don't remember to save my last copy as an XCF I would loose a lot of work.

        Comment


        • #19
          Originally posted by kayosiii View Post
          I like the separate save/export workflow - It means that I never loose layers etc because I accidently saved in the wrong format. I use gimp for texturing which means I am constantly updating a png (or dds) image to make changes in (say blender) if I don't remember to save my last copy as an XCF I would loose a lot of work.
          In that case it can help, but if you just want to do adjustments to an image and don't use layers, then it gets in the way. I guess it's not possible to please both Greeks and Trojans. I can see the benefits, but for now it's been a pain. Maybe it's just a matter of getting used to...

          Comment


          • #20
            Originally posted by victormoliveira View Post
            no, it's me. thanks
            I'm happy to answer any questions about the project.
            Well then, good luck with that and I really hope you succeed. Gimp is falling behind the "competition" in terms of performance.
            Oh, andif you get any free time and don't have anything better to do, how about improving the rendering backend in inkscape as well? :-D

            Comment


            • #21
              Originally posted by devius View Post
              Oh, andif you get any free time and don't have anything better to do, how about improving the rendering backend in inkscape as well? :-D
              You probably don't follow Inkscape's development closely. Head over to inkscape.org, I have some news there for you

              Comment


              • #22
                Originally posted by prokoudine View Post
                You probably don't follow Inkscape's development closely. Head over to inkscape.org, I have some news there for you
                Holy crap!! At long last!! Inkscape is so painfully slow right now... and it's sad to see it only use one core of my quad-core system. Can't wait for that 0.49 version. I thought that performance work wouldn't appear until version 0.50. Good news indeed.

                BTW, I do follow Inkscape's development and news, although not that frequently. A couple of weeks ago I read about some optimization work being worked on, but I was under the impression that it would take some time to materialize.

                Comment


                • #23
                  Originally posted by cl333r View Post
                  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.
                  "So it's really mostly up to the quality of the source code and the solutions it uses."

                  i think this is the only problem ;-)

                  right now it works.. but it makes mouse input lag... maybe they fix this in the future!..

                  then its maybe better maybe not faster on some old cards compared to new cpus but more energy efficiency sure

                  but right now it sucks!

                  Comment


                  • #24
                    Originally posted by wpoely86 View Post
                    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.
                    "The copying back and forth to the GPU will always be the bottleneck."

                    you are wrong in that point. the amd fusion3 with r900 (hd8000) graphic core do use the same 64bit address space and the same RAM as the CPU no copying back is needed!

                    Comment


                    • #25
                      Originally posted by devius View Post
                      Holy crap!! At long last!! Inkscape is so painfully slow right now... and it's sad to see it only use one core of my quad-core system.
                      LOL

                      Originally posted by devius View Post
                      Can't wait for that 0.49 version. I thought that performance work wouldn't appear until version 0.50. Good news indeed.
                      Actually there is a PPA with nightly builds for Ubuntu users, if you're interested.

                      Originally posted by devius View Post
                      BTW, I do follow Inkscape's development and news, although not that frequently. A couple of weeks ago I read about some optimization work being worked on, but I was under the impression that it would take some time to materialize.
                      As a matter of fact, the guy who works on performance in Inkscape had OpenCL based SVG filters in plans, but had to postpone it. He is still interested, though. We'll see how it works out

                      Comment


                      • #26
                        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?
                        no fusion1 with an hd5000 core and fusion 2 with an hd6950 core can not use the same 64bit address space
                        the fusion1+2 only do have chip logic to do the copy between the addressspaces faster ...

                        but the fusion3 in2012-2013 will have the hd8000(r900) graphik chip with the same 64bit adress space

                        then the gpu use 100% the same ram space.

                        but this is future 2012-2013.-

                        Comment


                        • #27
                          Originally posted by prokoudine View Post
                          The people who actually patched GIMP to make FilmGIMP which later became Cinepaint were the very same people who later started GEGL to do everything properly (i.e. not like in FilmGIMP/Cinepaint). But sure, you know better about silver plates and whatnot. Facts are soooo boring, aren't they?
                          So Rhythm & Hues and Sony Pictures Imageworks are supporting GEGL, BABL, etc.? Or are you confusing your easily verifiable facts?

                          Also: a working solution, no matter how ugly the code, is better than vaporware, when? Always.

                          Comment


                          • #28
                            Originally posted by yogi_berra View Post
                            So Rhythm & Hues and Sony Pictures Imageworks are supporting GEGL, BABL, etc.? Or are you confusing your easily verifiable facts?
                            Easily verifiable. You nailed it. Actually this is what you should have done prior to posting studying facts. You could, for example, go and check who and when worked on both FilmGIMP and GEGL. And you could find a mail from one of the R&H folks to gimp-developer@ from early December 2002 where he wrote about the R&H's perspective on both projects. Instead you seem to be holding a personal grudge against GEGL without having any clue about facts and you can't let go of it. Well, good luck spreading bullshit

                            Comment


                            • #29
                              Originally posted by prokoudine View Post
                              EAnd you could find a mail from one of the R&H folks to gimp-developer@ from early December 2002 where he wrote about the R&H's perspective on both projects. Instead you seem to be holding a personal grudge against GEGL without having any clue about facts and you can't let go of it. Well, good luck spreading bullshit
                              You could post links, but lets face it you enjoy flaming rather than having a civil conversation about vaporware.

                              Comment


                              • #30
                                Originally posted by yogi_berra View Post
                                You could post links, but lets face it you enjoy flaming rather than having a civil conversation about vaporware.
                                You mean a civil conversation is when you bullshit people instead of relying on facts and everyone nodes in agreement? I don't think so Yeah, I could post links, but how would bringing you facts "on a silver platter" possibly teach you to do research? I can help you to get started though.

                                Commit log for HOLLYWOOD branch
                                Commit log for GEGL
                                gimp-developer@ list archive for December 2002 (mail from Jonathan Cohen)

                                Let me know if you have problems understanding whose exactly the joint “People doing a 16 bpc version of gimp” account was that features in both GIMP and GEGL logs.

                                The fact is, FilmGIMP/Cinepaint was, is and will be a crippled solution. R&H team started to redo it properly with GEGL, and even the new team led by Robin started to redo everything properly with Glasgow (and failed). That's because engineers don't fall for crippled solutions, even if you personally expect them to waste time doing the opposite.

                                You start investing time into support of architecturally wrong code, you have less time for the right thing, so you end up with people not using your software, because it sucks. The amount of downloads Cinepaint got over last 4 years the builds of stable GIMP for Windows get in mere 2.something days (check download stats at Sourceforge). Users are intelligent enough to know what's good for them. Yes, Cinepaint doesn't get as much attention as GIMP, but could it be because it has a retarded UI and a feature set from ten years ago at best?

                                Let's face it: on a purely technical level both Cinepaint and GIMP/GEGL projects have issues. But one of them is alive and the other one is dead no matter how many times project "lead" promises a new release "soon, very soon, maybe next week".

                                Note that I wouldn't have to write any of that if you had skills to do a very basic research. it's really amazing how easily people who can't let go of their fav project failure distract other people from discussing a project that's alive and well.
                                Last edited by prokoudine; 08-20-2011, 01:07 PM.

                                Comment

                                Working...
                                X