1. 18 Dec, 2013 30 commits
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor_blockhandler: Don't do glFinish every time. · 9fcd123a
      Zhigang Gong authored
      To do glfinish every time bring some performance overhead.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      gradient: Disable gradient for gles2. · 6b664dda
      Zhigang Gong authored
      As PVR glsl compiler seems doesn't support external fragment
      function, and fails at compile gradient shader. Disable it
      for now. We may need to modify gradient shader to don't use
      external function.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor_pixmap_priv: Always return a valid private pixmap. · bd53e24d
      Zhigang Gong authored
      If a pixmap doesn't have a private, then set its type to
      GLAMOR_MEMORY, and thus it will get a valid private.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      fallback_optimize: Prepare for downloading/uploading subregion. · cea0fe3e
      Zhigang Gong authored
      Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap,
      can easily used to get and put sub region of a big textured pixmap.
      And it can use pbo if possible.
      To support download a big textured pixmap's sub region to another
      pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP.
      This type of pixmap has a valid devPrivate.ptr pointer, and that
      pointer points to a pbo mapped address.
      Now, we are ready to refine those
      glamor_prepare_access/glamor_finish_access pairs.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • 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
      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
      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
              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>
    • He Junyan's avatar
      Prepare for modification of gradient using shader. · ccf5d7f5
      He Junyan authored
       Prepare for modification of gradient using shader. The
       gradient pixmaps now is generated by pixman and we will
       replace them with shader. Add structure fields and
       dispatch functions which will be needed. Some auxiliary
       macro for vertex convert.
      Reviewed-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      For DRI swap buffers. · 213285f2
      Zhigang Gong authored
      This commit added two APIs to support the DRI swap buffer.
      one is glamor_egl_exchange_buffers() which can swap two
      pixmaps' underlying KHRimages/fbos/texs. The DDX layer should
      exchange the DRM bos to make them consistent to each other.
      Another API is glamor_egl_create_textured_screen_ext(), which
      extent one more parameters to track the DDX layer's back pixmap
      pointer. This is for the triple buffer support. When using triple
      buffer, the DDX layer will keep a back pixmap rather then the
      front pixmap and the pixmap used by the DRI2 client. And during
      the closing screen stage, we have to dereference all the back
      pixmap's glamor resources. Thus we have to extent this API to
      register it when create new screen.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • 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);
      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>
    • 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"
      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>
    • Zhigang Gong's avatar
      Don't call dixSetPrivate directly. · 1ab40028
      Zhigang Gong authored
      We may change the way to set/get those private data latter.
      consolidate to glamor_set_pixmap/screen_private is better
      than call those dixSetPrivate directly.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Refine CloseScreen and FreeScreen processes. · bf7d79dc
      Zhigang Gong authored
      This commit move the calling to glamor_close_screen from
      glamor_egl_free_screen to glamor_egl_close_screen, as this
      is the right place to do this.
      We should detach screen fbo and destroy the corresponding
      KHR image at glamor_egl_close_screen stage. As latter
      DDX driver will call DestroyPixmap to destroy screen pixmap,
      if the fbo and image are still there but glamor screen private
      data pointer has been freed, then it causes segfault.
      This commit also introduces a new flag GLAMOR_USE_EGL_SCREEN.
      if DDX driver is using EGL layer then should set this bit
      when call to glamor_init and then both glamor_close_screen
      and glamor_egl_close_screen will be registered correctly,
      DDX layer will not need to call these two functions manually.
      This way is also the preferred method within Xorg domain.
      As interfaces changed, bump the version to 0.3.0.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Tested-by: default avatarPeng Li <peng.li@intel.com>
    • Zhigang Gong's avatar
      glamor_create_fbo: Concentrate the fbo size/depth checking. · a1de528c
      Zhigang Gong authored
      Concentrate checking the size/depth when creating fbo. Simply
      the pixmap creation and the uploading fbo/texture preparing.
      Also slightly change the uploading fbo's preparation. If don't
      need fbo, then a fbo only has valid texture should be enough
      to return.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor-fbo-pool: Enable to reuse different size fbo/texture. · 9c6fd931
      Zhigang Gong authored
      Fixup three special cases, one is in tile and the other is in
      composite. Both cases are due to repeat texture issue. Maybe
      we can refine the shader to recalculate texture coords to
      support partial texture's repeating.
      The third is when upload a memory pixmap to texture, as now
      the texture may not have the exact size as the pixmap, we
      should not use the full rect coords.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • 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>
    • 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>
    • Zhigang Gong's avatar
      glamor_set_pixmap_texture/screen_pixmap: Remove useless parameters. · ca2ddd33
      Zhigang Gong authored
      As after we got a texture, no matter the texture is created
      on the glamor_create_pixmap or on the egl layer, we all already
      know the texture's width and height there. We don't need
      to pass them in.
      This commit also simply the glamor_egl_create_textured_screen to
      reuse the egl_create_textured_pixmap. And also remove the useless
      root image from the egl private structure. As now the root image
      is bound to the screen image, we don't take care it separately
      here. It will be freed at the screen closing.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      Release previous textre/fb when bind a new texture to a pixmap. · bdd72da0
      Zhigang Gong authored
      As we want to support DRI2 drawable which may create a new textured_drm
      to a pre-existing texture_only pixmap, we have to add this logical.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Tested-by: He Junyan<junyan.he@linux.intel.com>
    • Zhigang Gong's avatar
      Add glFinish after glFlush. · d7352d57
      Zhigang Gong authored
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      Code cleanup. · 3ba546b6
      Zhigang Gong authored
      Remove useless code, and after a fbCreatePixmap, we
      do not need to modify its header there.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Make sure the devPrivate.ptr of a textured pixmap is NULL. · 7285f2e8
      Zhigang Gong authored
      Just in case when wrongly fallback to DDX layer and cause
      random memory corruption. Pointed out by Chris.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • 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>
    • Zhigang Gong's avatar
      Classfy glamor pixmap to different types. · e3d16c9e
      Zhigang Gong authored
      During the integration with intel driver, we introduce two
      new type of pixmap, one is TEXTURE_DRM, the other is DRM_ONLY.
      TEXTURE_DRM means we create a texture bind to the DRM buffer
      successfully. And then the texture and the external BO is
      consistent. DRM_ONLY means that we failed to create a texture
      from the external DRM BO. We need to handle those different
      types carefully, so we have to track them in the data structure.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • 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>
    • Zhigang Gong's avatar
      Override create/destroy picture to track pict format. · b5480e64
      Zhigang Gong authored
      When create a piccture, we need to attach a pixmap to it.
      A pixmap only has a depth, which is not sufficant for glamor.
      As in openGL texture only has a few internal formats which
      is not sufficant to represent all the possible picture
      format. So we always transform the picture format to GL_RGBA.
      And when we need to read back the picture, we must know the
      original picture format. So we have to override create
      and destroy picture to track a pixmap's real picture format
      if it is attached to a picture.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      If caller is not using glamor screen, we can't register · 90eaac96
      Zhigang Gong authored
      the block handler.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Initial version. · b861aad8
      Zhigang Gong authored
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
  2. 26 Sep, 2011 10 commits