1. 03 Jun, 2017 1 commit
  2. 17 Mar, 2017 1 commit
  3. 10 Mar, 2016 2 commits
  4. 30 Jan, 2016 1 commit
  5. 10 Jul, 2015 1 commit
  6. 02 Jul, 2015 1 commit
  7. 30 Jun, 2015 1 commit
  8. 12 May, 2015 1 commit
  9. 24 Mar, 2015 2 commits
  10. 15 Jun, 2014 4 commits
    • Keith Packard's avatar
      glamor: Remove stubbed-out glamor_stipple function · a6aaa517
      Keith Packard authored
      This function isn't used anymore.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      a6aaa517
    • Keith Packard's avatar
      glamor: Add accelerated stipple support · bd3b2c48
      Keith Packard authored
      This copies the stipple to a 8bpp pixmap and uses that to paint the
      texture from.
      
      v2: Create deep stipple pixmap without GLAMOR_CREATE_FBO_NO_FBO
      
      v3: Fix stipple origin sign (matches tiles now). Track changes
          to original stipple with damage. This isn't required by the
          X spec, but java appears to depend on it, so we'll just do it.
          When Glamor switches to 8bpp bitmaps, we'll be able to render
          directly from them and not need this anymore.
      
      v4: Review comments from Eric:
      
          * Remove stray whitespace change
          * Avoid "large" pixmap for stipple by using GLAMOR_CREATE_NO_LARGE
          * Wrap to 80 columns
      
      v5: Don't crash when stipple damage tracker is destroyed
      
          The stipple damage tracker is automatically destroyed when the
          associated stipple pixmap is destroyed. When this happens, just
          clear the pointer from the GC rather than calling
          glamor_invalidate_stipple; that function would call
          DamageUnregister on the now invalid stipple damage pointer and
          crash.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      bd3b2c48
    • Keith Packard's avatar
      glamor: Add glamor_program based 0-width dashed lines · d18f5801
      Keith Packard authored
      This makes sure the pixelization for dashed lines matches non-dashed
      lines, while also speeding them up.
      
      v2: Switch to glamor_make_current
      
      v3: Create dash pattern pixmap without GLAMOR_CREATE_FBO_NO_FBO
      
      v4: Adopt suggestions from Eric's review:
      
        - Drops power-of-two alignment of our line vertex data, simplifying
          the code.
      
        - Stops reading from the VBO.  While on keithp's and my machines the
          VBO is mapped cached, on many implementations it will be mapped WC,
          making those reads extremely expensive.
      
        - Style fixes (line wrapping, spaces around operators).
      
      v5: Adopt suggestions from Markus' review:
      
        - Use max when computing zero-width dashed line length.
      
          Don't open code max here.
      
        - Embed CoordModePrevious into VBO writing for dashed lines
      
          Instead of pre-computing the coord mode previous results, just
          embed this in the loop which fills the vertex buffer. Saves
          re-writing the request buffer, and shortens the code a bit
      
      v6: Export glamor_destroy_gc for UXA
      
          UXA needs to call glamor_destroy_gc from its GCFuncs, so export
          it.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      d18f5801
    • 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
          keithp.
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      15e4d14d
  11. 23 Apr, 2014 1 commit
  12. 22 Apr, 2014 1 commit
  13. 03 Apr, 2014 2 commits
  14. 26 Mar, 2014 2 commits
  15. 17 Mar, 2014 5 commits
  16. 15 Feb, 2014 2 commits
  17. 27 Jan, 2014 2 commits
  18. 18 Dec, 2013 10 commits
    • Zhigang Gong's avatar
      Fixed some compilation warning/error or error checking. · 06ba3fdf
      Zhigang Gong authored
      There is one compilation error ,cast int to pointer, when built without
      libgbm, reported by Gaetan Nadon.
      And some error checking after memory allocation, reported by Seth Arnold.
      There are still some similar issues in the largepixmap implementation.
      They are relatively more complicate due to the heavy usage of RegionXXX
      APIs which may allocate implicitly. Will fix them in the future.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@intel.com>
      Tested-by: Gaetan Nadon's avatarGaetan Nadon <memsize@videotron.ca>
      06ba3fdf
    • Zhigang Gong's avatar
      Silence compilation warnings. · b8f0a218
      Zhigang Gong authored
      After increase to gcc4.7, it reports more warnings, now
      fix them.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Tested-by: Junyan He<junyan.he@linux.intel.com>
      b8f0a218
    • Zhigang Gong's avatar
      glamor_largepixmap: first commit for large pixmap. · ace35e40
      Zhigang Gong authored
      This is the first commit to add support for large pixmap.
      The large here means a pixmap is larger than the texutre's
      size limitation thus can't fit into one single texutre.
      
      The previous implementation will simply fallback to use a
      in memory pixmap to contain the large pixmap which is
      very slow in practice.
      
      The basic idea here is to use an array of texture to hold
      the large pixmap. And when we need to get a specific area
      of the pixmap, we just need to compute/clip the correct
      region and find the corresponding fbo.
      
      We need to implement some auxiliary routines to clip every
      rendering operations into small pieces which can fit into
      one texture.
      
      The complex part is the transformation/repeat/repeatReflect
      and repeat pad and their comination. We will support all of
      them step by step.
      
      This commit just add some necessary data structure to represent
      the large pixmap, and doesn't change any rendering process.
      This commit doesn't add real large pixmap support.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      ace35e40
    • Zhigang Gong's avatar
      Fixed a stride problem for textured_drm pixmap. · ff3d2c79
      Zhigang Gong authored
      As a textured_drm pixmap has a drm bo attached to it, and
      it's the DDX layer to set it stride value. In some case,
      the stride value is not equal to PixmapBytePad(w, depth)
      which is used within glamor.
      
      Then if it is the case, we have two choice, one is to set
      the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need
      to download or upload the pixmap. The other option is to
      change the pixmap's devKind to match the one glamor is using
      when downloading the pixmap, and restore it to the drm stride
      after uploading the pixmap.
      
      We choose the 2nd option, as GLES doesn't support the first
      method.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      ff3d2c79
    • Zhigang Gong's avatar
      gles2: Fixed color conversion for the formats except 1555 and 2101010. · 3add3750
      Zhigang Gong authored
      This patch fixed two major problems when we do the color convesion with
      GLES2.
      
      1. lack of necessary formats in FBO pool.
      GLES2 has three different possible texture formats, GL_RGBA,
      GL_BGRA and GL_ALPHA. Previous implementation only has one bucket
      for all the three formats which may reuse a incorrect texture format
      when do the cache lookup. After this fix, we can enable fbo safely
      when running with GLES2.
      
      2. Refine the format matching method in
      glamor_get_tex_format_type_from_pictformat.
      If both revertion and swap_rb are needed, for example use GL_RGBA
      to represent PICT_b8g8r8a8. Then the downloading and uploading should
      be handled differently.
      
          The picture's format is PICT_b8g8r8a8,
          Then the expecting color layout is as below (little endian):
          0   1       2       3   : address
          a   r       g       b
      
          Now the in GLES2 the supported color format is GL_RGBA, type is
          GL_UNSIGNED_TYPE, then we need to shuffle the fragment
          color as :
              frag_color = sample(texture).argb;
          before we use glReadPixel to get it back.
      
          For the uploading process, the shuffle is a revert shuffle.
          We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color
          to a texture, then let's see
          0   1       2       3   : address
          a   r       g       b   : correct colors
          R   G       B       A   : GL_RGBA with GL_UNSIGNED_BYTE
      
          Now we need to shuffle again, the mapping rule is
          r = G, g = B, b = A, a = R. Then the uploading shuffle is as
          below:
              frag_color = sample(texture).gbar;
      
      After this commit, gles2 version can pass render check with all
      the formats except those 1555/2101010.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      3add3750
    • Chris Wilson's avatar
      Fixup glx support · 556adfa6
      Chris Wilson authored
      Renaming glamor_priv->dispatch and wrapping the access to
      the dispatch table with a function that also ensured the
      context was bound.
      
       dispatch = glamor_get_dispatch(glamor_priv);
       ...
       glamor_put_dispatch(glamor_priv);
      
      So that we catch all places where we attempt to call into GL withouta
      context. As an optimisation we can then do glamor_get_context();
      glamor_put_context() around the rendering entry points to reduce the
      frequency of having to restore the old context. (Along with allowing
      the context to be recursively acquired and making the old context part of
      the glamor_egl state.)
      Reviewed-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      556adfa6
    • Zhigang Gong's avatar
      prepare_access: Don't use fbo after it was downloaded. · 39d9e6c6
      Zhigang Gong authored
      We add a new gl_fbo status GLAMOR_FBO_DOWNLOADED to indicate
      the fbo was already downloaded to CPU. Then latter the access
      to this pixmap will be treated as pure CPU access. In glamor,
      if we fallback to DDX/fbXXX, then we fallback everything
      currently. We don't support to jump into glamor acceleration
      layer between a prepare_access/finish_access. Actually, fbCopyPlane
      is such a function which may call to acceleration function within
      it. Then we must mark the downloaded pixmap to another state
      rather than a normal fbo textured pixmap, and then stick to use
      it as a in-memory pixmap.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Tested-by: default avatarPeng Li <peng.li@intel.com>
      39d9e6c6
    • Zhigang Gong's avatar
      glamor-fbo-pool: Implement fbo cache mechanism. · c7e79d6a
      Zhigang Gong authored
      We classify the cache according to the texture's format/width/height.
      As openGL doesn't allow us to change a texture's format/width/height
      after the internal texture object is already allocated, we can't
      just calculate the size and then according ths size to put the
      fbo to an bucket which is just like SNA does. We can only put
      the fbo to the corresponding format/width/height bucket.
      
      This commit only support the exact size match. The following patch
      will remove this restriction, just need to handle the repeat/tile
      case when the size is not exactly match.
      
      Should use fls instead of ffs when decide the width/height bucket,
      thanks for Chris to point this out.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      c7e79d6a
    • Zhigang Gong's avatar
      glamor_fbo: Introduce glamor fbo to manage all the fb/tex. · 2ff41008
      Zhigang Gong authored
      This is the first patch to implement a fbo/tex pool mechanism which
      is like the sna's BO cache list. We firstly need to decopule the
      fbo/tex from each pixmap. The new glamor_pixmap_fbo data
      structure is for that purpose. It's somehow independent to each
      pixmap and can be reused latter by other pixmaps once it's detached
      from the current pixmap.
      
      And this commit also slightly change the way to create a
      memory pixmap. We will not create a pixmap private data structure
      by default, instead we will crete that structure when a memory
      pixmap is attaching a fbo to it.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      2ff41008
    • Zhigang Gong's avatar
      Reduce the double check of pixmap's private pointer. · a65e1c73
      Zhigang Gong authored
      As we now add the checking to the Macro, we don't need to check
      the pointer outside the Macro.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      a65e1c73