Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 56

Thread: OpenCL Is Coming To The GIMP Via GEGL

  1. #21
    Join Date
    Jan 2011
    Posts
    58

    Default

    Quote 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

  2. #22
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    Quote 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.

  3. #23
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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!

  4. #24
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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!

  5. #25
    Join Date
    Jan 2011
    Posts
    58

    Default

    Quote 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

    Quote 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.

    Quote 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

  6. #26
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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.-

  7. #27
    Join Date
    Oct 2008
    Posts
    888

    Default

    Quote 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.

  8. #28
    Join Date
    Jan 2011
    Posts
    58

    Default

    Quote 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

  9. #29
    Join Date
    Oct 2008
    Posts
    888

    Default

    Quote 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.

  10. #30
    Join Date
    Jan 2011
    Posts
    58

    Default

    Quote 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 at 01:07 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •