1. 30 Jan, 2016 8 commits
  2. 26 Jan, 2016 4 commits
  3. 22 Jan, 2016 1 commit
  4. 10 Nov, 2015 1 commit
    • Eric Anholt's avatar
      glamor: Fix segfault in fallback picture uploading. · 9a597280
      Eric Anholt authored
      If the source/mask pixmap is a pixmap that doesn't have an FBO
      attached, and it doesn't match the Render operation's size, then we'll
      composite it to a CPU temporary (not sure why).  We would take the
      PictFormatShort from the source Picture, make a pixmap of that depth,
      and try to look up the PictFormat description from the depth and the
      PictFormatShort.  However, the screen's PictFormats are only attached
      to the screen's visuals' depths.  So, with an x2r10g10b10 short format
      (depth 30), we wouldn't find the screen's PictFormat for it
      (associated with depth 32).
      Instead of trying to look up from the screen, just use the pFormat
      that came from our source picture.  The only time we need to look up a
      PictFormat when we're doing non-shader gradients, which we put in
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
  5. 10 Jul, 2015 2 commits
  6. 02 Jul, 2015 3 commits
  7. 30 Jun, 2015 2 commits
  8. 02 Jun, 2015 1 commit
  9. 14 May, 2015 1 commit
    • Keith Packard's avatar
      glamor: Replace CompositeGlyphs code [v2] · b0d2e010
      Keith Packard authored
      New composite glyphs code uses the updated glamor program
      infrastructure to create efficient shaders for drawing render text.
      Glyphs are cached in two atlases (one 8-bit, one 32-bit) in a simple
      linear fashion. When the atlas fills, it is discarded and a new one
      v2: Eric Anholt changed the non-GLSL 130 path to use quads instead of
      two triangles for a significant performance improvement on hardware
      with quads. Someone can fix the GLES quads emulation if they want to
      make it faster there.
      v3: Eric found more dead code to delete
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
  10. 24 Mar, 2015 6 commits
  11. 18 Jul, 2014 2 commits
  12. 17 Jul, 2014 1 commit
    • Keith Packard's avatar
      glamor: Fix temp picture coordinates in glamor_composite_clipped_region · 55f5bfb5
      Keith Packard authored
      To understand this patch, let's start at the protocol interface where
      the relationship between the coordinate spaces is documented:
              static Bool
              _glamor_composite(CARD8 op,
                                PicturePtr source,
                                PicturePtr mask,
                                PicturePtr dest,
                                INT16 x_source,
                                INT16 y_source,
                                INT16 x_mask,
                                INT16 y_mask,
                                INT16 x_dest, INT16 y_dest,
                                CARD16 width, CARD16 height, Bool fallback)
      The coordinates are passed to this function directly off the wire and
      are all relative to their respective drawables. For Windows, this means
      that they are relative to the upper left corner of the window, in
      whatever pixmap that window is getting drawn to.
      _glamor_composite calls miComputeCompositeRegion to construct a clipped
      region to actually render to. In reality, miComputeCompositeRegion clips
      only to the destination these days; source clip region based clipping
      would have to respect the transform, which isn't really possible. The
      returned region is relative to the screen in which dest lives; offset by
      dest->drawable.x and dest->drawable.y.
      What is important to realize here is that, because of clipping, the
      composite region may not have the same position within the destination
      drawable as x_dest, y_dest. The protocol coordinates now exist solely to
      'pin' the three objects together.
              extents->x1,y1		Screen origin of clipped operation
              width,height            Extents of the clipped operation
              x_dest,y_dest		Unclipped destination-relative operation coordinate
              x_source,y_source	Unclipped source-relative operation coordinate
              x_mask,y_mask		Unclipped mask-relative operation coordinate
      One thing we want to know is what the offset is from the original
      operation origin to the clipped origin
              Destination drawable relative coordinates of the clipped operation:
                     x_dest_clipped = extents->x1 - dest->drawable.x
                     y_dest_clipped = extents->y1 - dest->drawable.y
              Offset from the original operation origin:
                      x_off_clipped = x_dest_clipped - x_dest
                      y_off_clipped = y_dest_clipped - y_dest
              Source drawable relative coordinates of the clipped operation:
                      x_source_clipped = x_source + x_off_clipped;
                      y_source_clipped = y_source + y_off_clipped;
              Mask drawable relative coordinates of the clipped operation:
                      x_mask_clipped = x_source + x_off_clipped;
                      y_mask_clipped = y_source + y_off_clipped;
      This is where the original code fails -- it doesn't subtract the
      destination drawable location when computing the distance that the
      operation has been moved by clipping. Here's what it does when
      constructing a temporary source picture:
              temp_src =
                  glamor_convert_gradient_picture(screen, source,
                                                  extent->x1 + x_source - x_dest,
                                                  extent->y1 + y_source - y_dest,
                                                  width, height);
              x_temp_src = -extent->x1 + x_dest;
              y_temp_src = -extent->y1 + y_dest;
      glamor_convert_gradient_picture needs source drawable relative
      coordinates, but that is not what it's getting; it's getting
      screen-relative coordinates for the destination, adjusted by the
      distance between the provided source and destination operation
      coordinates. We want x_source_clipped and y_source_clipped:
              x_source_clipped = x_source + x_off_clipped
                               = x_source + x_dest_clipped - x_dest
                               = x_source + extents->x1 - dest->drawable.x - x_dest
      x_temp_src/y_temp_src are supposed to be the coordinates of the original
      operation translated to the temporary picture:
              x_temp_src = x_source - x_source_clipped;
              y_temp_src = y_source - y_source_clipped;
      Note that x_source_clipped/y_source_clipped will never be less than
      x_source/y_source because all we're doing is clipping. This means that
      x_temp_src/y_temp_src will always be non-positive; the original source
      coordinate can never be strictly *inside* the temporary image or we
      could have made the temporary image smaller.
              x_temp_src = x_source - x_source_clipped
                         = x_source - (x_source + x_off_clipped)
                         = -x_off_clipped
                         = x_dest - x_dest_clipped
                         = x_dest - (extents->x1 - dest->drawable.x)
      Again, this is off by the destination origin within the screen
      coordinate space.
      The code should look like:
              temp_src =
                  glamor_convert_gradient_picture(screen, source,
                                                  extent->x1 + x_source - x_dest - dest->pDrawable->x,
                                                  extent->y1 + y_source - y_dest - dest->pDrawable->y,
                                                  width, height);
              x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x;
              y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y;
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: default avatarMarkus Wick <markus@selfnet.de>
  13. 24 Jun, 2014 1 commit
  14. 15 Jun, 2014 2 commits
    • Keith Packard's avatar
      glamor: Add glamor_program based copy acceleration · 45ebc4e3
      Keith Packard authored
      Paints with textures, using a temporary buffer for overlapping copies
      Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy
      plane when both objects are in the GPU. Includes copy_window
      acceleration too.
      v2: Use NV_texture_barrier for non-overlapping copies within the same
      v3: Switch to glamor_make_current
      v4: Do overlap check on the bounding box of the region rather than
          on individual boxes
      v5: Use Eric Anholt's re-written comments which provide a more accurate
          description of the code
      v6: Use floating point uniform for copy plane bit multiplier. This
          avoids an int to float conversion in the copy plane fragment shader.
          Use round() instead of adding 0.5 in copy plane. round() and +0.5
          end up generating equivalent code, and performance measurements
          confirm that they are the same speed. Round() is a bit clearer
          though, so we'll use it.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarMarkus Wick <markus@selfnet.de>
    • 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: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
  15. 23 Apr, 2014 3 commits
  16. 22 Apr, 2014 1 commit
    • Eric Anholt's avatar
      glamor: Fix accelerated rendering of GTK's ARGB vs xBGR composites. · e9240342
      Eric Anholt authored
      There is some complicated code to support tweaking the format as we
      upload from a SHM pixmap (aka the GTK icon cache), but if we weren't
      sourcing from a SHM pixmap we just forgot to check that the formats
      matched at all.
      We could potentially be a little more discerning here (xRGB source and
      ARGB mask would be fine, for example), but this will all change with
      texture views anyway, so just get the rendering working for 1.16
      Fixes the new rendercheck gtk_argb_xbgr test.
      v2: Squash in keithp's fix for checking that we have a non-NULL
          pixmap, and reword the comment even more.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
  17. 26 Mar, 2014 1 commit