1. 02 Jul, 2018 5 commits
    • Øyvind "pippin" Kolås's avatar
      workshop: remove discardable protoype op enlarge2 · c884049d
      Øyvind "pippin" Kolås authored
      It consumes too much time during build of docs/operations when workshop is
    • Øyvind "pippin" Kolås's avatar
      tests: update clones reference · efb5e505
      Øyvind "pippin" Kolås authored
    • Øyvind "pippin" Kolås's avatar
    • Ell's avatar
      buffer: use gegl_tile_read_{lock,unlock}() when reading tiles · 7fe8beab
      Ell authored
      Use the new gegl_tile_read_lock() and gegl_tile_read_unlock()
      functions, added in the previous commit, before/after reading from
      a tile in a potentially-multithreaded context.
      See the previous commit for an explanation of why this is
      Note, in particular, that this may make 1x1 gegl_buffer_get()s
      (and NEAREST gegl_buffer_sample()) more expensive, however, NEAREST
      sampler objects amortize the cost of these functions by only
      locking/unlocking the sampler's hot-tile when switching tiles.  As
      a result, a concurrent write to the same buffer may block while the
      sampler object is alive.  We assume that buffers may not be
      written-to while there are active sampler objects constructed for
      them (which can already lead to stale data in the samplers).
    • Ell's avatar
      buffer: add gegl_tile_read_{lock,unlock}() · 301b798b
      Ell authored
      Currently, we don't manage read access to tile data -- code that
      reads from a tile simply calls gegl_tile_get_data(), and assumes
      the returned pointer is valid throghout.  This, however, might not
      be the case in general, in a multithreaded context:
      Suppose tiles A and B share the same data.  Thread 1 begins reading
      tile A through the pointer returned by gegl_tile_get_data().
      Thread 2 then locks tile A for writing (intending to write to a
      portion of the tile that doesn't overlap the portion thread 1 is
      reading).  Since the tile's data is shared, thread 2 unclones the
      data before writing, and so the data thread 1 is reading is now
      solely owned by tile B.  At this point, two things can go wrong:
      a concurrent write operation to tile B can overwrite the data
      thread 1 is reading (which supposedly belongs to tile A), or,
      tile B can be destroyed, freeing the data thread 1 is reading.
      To fix this, we add the gegl_tile_read_lock() and
      gegl_tile_read_unlock() functions, which "lock" the tile for read
      access.  Code that reads tile data should call these functions
      before/after reading from the tile, if the read may happen in a
      multithreaded context.  Note that in spite of the functions' names,
      they don't actually block execution in general.  Instead, they make
      sure that if gegl_tile_lock() is called on a cloned tile while it's
      being read, the function will block until reading is done before
      uncloning the tile.
      One exception to the above are clones of the global empty tile, for
      which we avoid the said blocking altogether, since their data may
      never end up being owned by a single, mutable tile.
      Using gegl_tile_lock/unlock() before/after writing, and
      gegl_tile_read_lock/unlock() before/after reading, guarantees that
      the following combinations of concurrent tile operations are safe:
        - Read/read.
        - Read/duplicate.
        - Duplicate/duplicate.
        - Non-overlapping read/write.
        - Non-overlapping write/write.
  2. 01 Jul, 2018 8 commits
  3. 30 Jun, 2018 3 commits
  4. 26 Jun, 2018 1 commit
  5. 24 Jun, 2018 1 commit
  6. 21 Jun, 2018 3 commits
  7. 19 Jun, 2018 2 commits
  8. 17 Jun, 2018 2 commits
  9. 15 Jun, 2018 2 commits
  10. 12 Jun, 2018 1 commit
  11. 10 Jun, 2018 1 commit
  12. 06 Jun, 2018 1 commit
  13. 05 Jun, 2018 6 commits
  14. 04 Jun, 2018 1 commit
  15. 03 Jun, 2018 1 commit
  16. 01 Jun, 2018 1 commit
    • orbea's avatar
      Fix build with slibtool. · 6931adcd
      orbea authored
      When building gegl with slibtool instead of libtool the build fails.
        /usr/bin/ld: cannot find -lpoly2tri-c
      I bisected this issue to the follow commit and it appears to be a gegl
  17. 30 May, 2018 1 commit