1. 16 Jul, 2015 1 commit
  2. 10 Jul, 2015 1 commit
    • Eric Anholt's avatar
      glamor: Take transforms into account when preparing for a fallback. · c1111710
      Eric Anholt authored
      This function takes the start x/y and the destination's width/height,
      so it only works if there's no transform.  We could potentially
      transform this box and take its bounds with some rounding, but this at
      least gets us to read out enough data.
      Note that this does the same overshoot on destination pictures with a
      transform attached, but that seems unlikely to be used anyway.
      v2: Add XXX comment for the commit message note (Suggested by Michel).
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
      Reviewed-by: Dave Airlie <airlied@redhat.com> (v1)
  3. 21 Apr, 2015 1 commit
  4. 24 Mar, 2015 1 commit
  5. 29 Sep, 2014 1 commit
  6. 15 Jun, 2014 1 commit
    • Keith Packard's avatar
      glamor: Replace fallback preparation code · 15e4d14d
      Keith Packard authored
      These offer a simpler and more efficient means for temporarily
      transitioning to CPU-accessible memory for fallback implementations.
      v2: Do not attempt fallbacks with GLAMOR_DRM_ONLY pixmaps
          glamor cannot transfer pixels for GLAMOR_DRM_ONLY pixmaps using
          glReadPixels and glTexSubImage2D, and so there's no way to perform
          fallback operations with these pixmaps.
      v3: Clear ->pbo field when deleting the PBO.  Otherwise, we'd reuse
          the old name next time we fall back on the pixmap, which would
          potentially conflict with some other pixmap that genned a new
          name, or just do a lazy allocation of the name (compat GL context,
          like we currently use) or error out (core GL context, like we hope
          to use some day).  Also, style fixes.  Changes by anholt, acked by
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>