1. 26 Jan, 2016 2 commits
    • Dave Airlie's avatar
      glamor: Add support for CA rendering in a single pass. · e7308b6c
      Dave Airlie authored
      It's been on the list to add dual source blending support to avoid the
      two pass componentAlpha code.  Radeon has done this for a while in
      EXA, so let's add support to bring glamor up to using it.
      This adds dual blend to both render and composite glyphs paths.
      Initial results show close to doubling of speed of x11perf -rgb10text.
      v2: Fix breakage of all of CA acceleration for systems without
          GL_ARB_blend_func_extended.  Add CA support for all the ops we
          support in non-CA mode when blend_func_extended is present.  Clean
          up some comments and formatting.  (changes by anholt)
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
    • Eric Anholt's avatar
      glamor: Drop the composite_with_copy path entirely. · cab14a9a
      Eric Anholt authored
      I originally inherited this from the EXA code, without determining
      whether it was really needed.  Regular composite should end up doing
      the same thing, since it's all just shaders anyway.  To the extent
      that it doesn't, we should fix composite.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
  2. 22 Jan, 2016 1 commit
  3. 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>
  4. 10 Jul, 2015 2 commits
  5. 02 Jul, 2015 3 commits
  6. 30 Jun, 2015 2 commits
  7. 02 Jun, 2015 1 commit
  8. 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>
  9. 24 Mar, 2015 6 commits
  10. 18 Jul, 2014 2 commits
  11. 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>
  12. 24 Jun, 2014 1 commit
  13. 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>
  14. 23 Apr, 2014 3 commits
  15. 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>
  16. 26 Mar, 2014 2 commits
  17. 17 Mar, 2014 5 commits
  18. 10 Mar, 2014 4 commits
    • Eric Anholt's avatar
      glamor: Fix requested composite VBO size. · 9b86f7a1
      Eric Anholt authored
      The argument to setup_composte_vbo is the number of verts.
      v2: Drop the now-unused vert_stride value.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Markus Wick <markus at selfnet.de>
    • Eric Anholt's avatar
      glamor: Extract the streamed vertex data code used by Render. · d310d566
      Eric Anholt authored
      We should be uploading any vertex data using this kind of upload
      style, since it saves a bunch of extra copies of our vertex data.
        - Add a simple comment about what the function does.
        - Use get_vbo_space()'s return in trapezoids, instead of dereffing
          glamor_priv->vb (by Markus Wick).
        - Fix the double-unmapping by moving put_vbo_space() outside of
        - Remove the rest of the composite_vbo_offset usage, and just always
          use get_vbo_space()'s return value.
        - Fix failure to put_vbo_space in traps when no prims were
        - Unbind the VBO from put_vbo_space().  Keeps callers from
          forgetting to do so.
        - Split out some changes into the previous 3 commits while trying to
          track down a regression.
        - Fix regression due to rebase fail where glamor_priv->vbo_offset
          wasn't incremented.
        - Fix GLES2 VBO sizing.
        - Add a comment about resize behavior.
        - Move glamor_vbo.c init code to glamor_vbo.c from
          glamor_render.c. (Derived from Markus's changes, but the GLES2 fix
          dropped almost all of the code in the functions).
        - Drop the initial BufferData on GLES2 (it happens at put() time).
        - Don't forget to set vbo_offset to the size on GLES2.
        - Use char * instead of void * in the cast to return the vbo_offset.
        - Resize the default FBO to 512kb, to be similar to previous
          behavior.  +1.66124% +/- 0.284223% (n=679) on aa10text.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Markus Wick <markus at selfnet.de>
    • Eric Anholt's avatar
      glamor: Track the next vertex offset as we go in render accel. · 03a33048
      Eric Anholt authored
      I want to extract the VBO mapping code, and as part of that I need to
      get the global vbo_offset munging to stop.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Markus Wick <markus at selfnet.de>
    • Eric Anholt's avatar
      glamor: Move glamor_emit_composite_vert() to traps, where it's used. · 438d8ace
      Eric Anholt authored
      It's only used in the nonantialiased, triangle-based trapezoids path.
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Markus Wick <markus at selfnet.de>