1. 23 Apr, 2014 1 commit
  2. 17 Mar, 2014 4 commits
  3. 15 Feb, 2014 5 commits
  4. 27 Jan, 2014 1 commit
  5. 18 Dec, 2013 27 commits
    • Michel Dänzer's avatar
      Don't use glBlitFramebufferEXT for overlapping copies. · 14e02f51
      Michel Dänzer authored
      According to the GL_EXT_framebuffer_blit spec, the result of doing so is
      undefined. But we need well-defined results. :)
      Signed-off-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      14e02f51
    • 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_copyarea: Use blitcopy if current state is not render. · 32a7438b
      Zhigang Gong authored
      Practically, for pure 2D blit, the blit copy is much faster
      than textured copy. For the x11perf copywinwin100, it's about
      3x faster. But if we have heavy rendering/compositing, then use
      textured copy will get much better (>30%)performance for most
      of the cases.
      
      So we simply add a data element to track current state. For
      rendering state we use textured copy, otherwise, we use blit
      copy.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      32a7438b
    • Zhigang Gong's avatar
      glamor_copyarea: Fixed a bug introduced by 996194... · 90dd6ddb
      Zhigang Gong authored
      Default return value should be FALSE.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      90dd6ddb
    • Zhigang Gong's avatar
      copyarea: Cleanup the error handling logic. · 01699533
      Zhigang Gong authored
      Should use ok rather than mixed ok or ret.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      01699533
    • Zhigang Gong's avatar
      largepixmap: Fix the selfcopy issue. · 8ca16754
      Zhigang Gong authored
      If the source and destination are the same pixmap/fbo, and we
      need to split the copy to small pieces. Then we do need to
      consider the sequence of the small pieces when the copy area
      has overlaps. This commit take the reverse/upsidedown into
      the clipping function, thus it can generate correct sequence
      and avoid corruption self copying.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      8ca16754
    • Zhigang Gong's avatar
      largepixmap: Implement infrastructure for large pixmap. · e96ea020
      Zhigang Gong authored
      Added infrastructure for largepixmap, this commit implemented:
      1. Create/Destroy large pixmap.
      2. Upload/Download large pixmap.
      3. Implement basic repeat normal support.
      3. tile/fill/copyarea large pixmap get supported.
      
      The most complicated part glamor_composite still not implemented.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      e96ea020
    • 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
      glamor_set_destination_pixmap_priv_nc: set drawable's width x height. · 81692804
      Zhigang Gong authored
      Previous implementation set the whole fbo's width and height as the
      viewpoint. This may increase the numerical error as we may only has
      a partial region as the valid pixmap. So add a new marco
      pixmap_priv_get_dest_scale to get proper scale factor for the
      destination pixmap. For the source/mask pixmap, we still need to
      consider the whole fbo's size.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      81692804
    • Zhigang Gong's avatar
      1035fc72
    • Zhigang Gong's avatar
      5c1f15fa
    • Zhigang Gong's avatar
      glamor_copyarea: Return earlier if have zero nbox. · 1f83411c
      Zhigang Gong authored
      Almost all callers will check whether the regions is empty
      before call to this internal API, but it seems the
      glamor_composite_with_copy may call into here with a zero
      nbox. A little weird, as the miComputeCompositeRegion return
      a Non-NULL, but the region is empty.
      
      Also remove a unecessary glflush.
      
      So let's check it here.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      1f83411c
    • Zhigang Gong's avatar
      glamor_copyarea: Don't access a DRM only pixmap. · 8a85071e
      Zhigang Gong authored
      As EGL image/gbm only support ARGB8888 image, we don't support
      other format. We may change the way to use gbm directly latter.
      But now, we have to face this limitation, and thus if a client
      create a 16bpp drawable, and call get texture from pixmap then
      a copy to here may occur and thus we have to force retur a TRUE
      without do nothing.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      8a85071e
    • Zhigang Gong's avatar
      pending_op: Remove the pending operations handling. · 9bcddff9
      Zhigang Gong authored
      We have disabled this feature for a long time, and previous
      testing shows that this(pending fill) will not bring observed
      performance gain. Now remove it.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      9bcddff9
    • Zhigang Gong's avatar
      glamor_set_alu: Fallback for non GXcopy ops with GLES2. · 3e9c35bd
      Zhigang Gong authored
      As GLES2 doesn't support LogiOps, we have to fallback
      here. GLES2 programing guide's statement is as below:
      
      "In addition, LogicOp is removed as it is very
      infrequently used by applications and the OpenGL ES
      working group did not get requests from independent
      software vendors (ISVs) to support this feature in
      OpenGL ES 2.0."
      
      So, I think, fallback here may not a big deal ;).
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      3e9c35bd
    • 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
    • Zhigang Gong's avatar
      glamor_copyarea: Don't use GL_CLAMP_TO_BORDER when GLES2 enabled. · 8012b030
      Zhigang Gong authored
      We may need to modify all the shader to handle GL_CLAMP_TO_BORDER
      when using GLES2. XXX, for now, we just ignore them.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      8012b030
    • 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
      GLX: Enable glx support. · 430bc16c
      Zhigang Gong authored
      If we are using MESA as our GL library, then both xserver's
      GLX and glamor are link to the same library. As xserver's
      GLX has its own _glapi_get/set_context/dispatch etc, and it
      is a simplified version derived from mesa thus is not
      sufficient for mesa/egl's dri loader which is used by glamor.
      
      Then if glx module is loaded before glamoregl module, the
      initialization of mesa/egl/opengl will not be correct, and
      will fail at a very early stage, most likely fail to map
      the element buffer.
      
      Two methodis to fix this problem, first is to modify the xserver's
      glx's glapi.c to fit mesa's requirement. The second is to put
      a glamor.conf as below, to the system's xorg.conf path.
      
      Section "Module"
              Load  "glamoregl"
      EndSection
      
      Then glamor will be loaded firstly, and the mesa's libglapi.so
      will be used. As current xserver's dispatch table is the same
      as mesa's, then the glx's dri loader can work without problem.
      
      We took the second method as it don't need any change to xorg.:)
      Although this is not a graceful implementation as it depends
      on the xserver's dispatch table and the mesa's dispatch table
      is the same and the context set and get is using the same method.
      Anyway it works.
      
      As by default, xserver will enable GLX_USE_TLS. But mesa will not
      enable it, you may need to enable that when build mesa.
      
      Three pre-requirements to make this glamor version work:
      
      0. Make sure xserver has commit 66e603, if not please pull the latest
         master branch.
      1. Rebuild mesa by enable GLX_USE_TLS.
      2. Put the glamor.conf to your system's xorg.conf path and make sure
         it loaded prior to glx module.
      
      Preliminary testing shows indirect glxgears works fine.
      
      If user want to use GLES2 for glamor by using MESA, GLX will not
      work correctly.
      
      If you are not using normal MESA, for example PVR's private GLES
      implementation, then it should be ok to use GLES2 glamor and the
      GLX should work as expected. In this commit, I use gbm to check
      whether we are using MESA or non-mesa. Maybe not the best way.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      430bc16c
    • Chris Wilson's avatar
      Use CLAMP_TO_BORDER in copy_n_to_n so we can sample outside of the source · 97efbd25
      Chris Wilson authored
      In order to reduce a composite operation to a source, we need to provide
      Render semantics for the pixel values of samples outside of the source
      pixmap, i.e. they need to be rgba(0, 0, 0, 0). This is provided by using
      the CLAMP_TO_BORDER repeat mode, but only if the texture has an alpha
      channel.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      97efbd25
    • 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
    • Zhigang Gong's avatar
      glamor-for-ddx: Exports all rendering/drawing functions. · 8c7fcefb
      Zhigang Gong authored
      This commit exports all the rest rendering/drawing functions
      to the DDX drivers. And introduce some new pixmap type. For
      a pixmap which has a separated texture, we never fallback
      it to the DDX layer.
      
      This commit also adds the following new functions:
      glamor_composite_rects, glamor_get_image_nf which are needed
      by UXA framework. Just a simple wrapper function of miXXX.
      Will consider to optimize them next few weeks.
      
      This commit also Fixed a glyphs rendering bug pointed by Chris.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      8c7fcefb
    • Zhigang Gong's avatar
      Call glamor_create_pixmap directly in glamor rendering path. · 36d424fe
      Zhigang Gong authored
      When glamor is rendering pixmaps, and needs to create some
      temporary pixmap, it's better to use glamor version create
      pixmap directly. As if goes to external DDX's create pixmap,
      it may create a external DRM buffer which is not necessary.
      All the case within glamor scope is to create a texture only
      pixmap or a in memory pixmap.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      36d424fe
    • Zhigang Gong's avatar
      Remove the access mode from private pixmap structure. · 92fd8387
      Zhigang Gong authored
      Change the finish_access to pass in the access mode, and remove
      the access mode from the pixmap structure. This element should
      not be a pixmap's property.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      92fd8387
    • Zhigang Gong's avatar
      exports more rendering functions to DDX driver. · b5630663
      Zhigang Gong authored
      Exports all necessary rendering functions to DDx drivers, including
      CopyArea, Glyphs, Composite, Triangles, ....
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      b5630663
    • Zhigang Gong's avatar
      Initial version. · b861aad8
      Zhigang Gong authored
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      b861aad8
  6. 26 Sep, 2011 2 commits