1. 18 Dec, 2013 16 commits
  2. 26 Sep, 2011 24 commits
    • Zhigang Gong's avatar
      glamor: Refine the screen pixmap initialization for Xephyr. · fe4c95ce
      Zhigang Gong authored
      The previous implementation is to override the CreatePixmap
      firstly and assume the first call to CreatePixmap must be
      screen pixmap. This is not clean. Now Refine it to normal
      way. Let the Xephyr to set texture 0 to screen pixmap
      during creating screen resources.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Correct the version check for GLES2. · 937d3bce
      Zhigang Gong authored
      If we are using GLES2, then the version number should be no
      less than 2.0 rather than no less than 1.3 which is for GL
    • Zhigang Gong's avatar
      glamor: Don't direct call to any gl functions. · 0dff23d6
      Zhigang Gong authored
      Create a new structure glamor_gl_dispatch to hold all the
      gl function's pointer and initialize them at run time ,
      rather than use them directly. To do this is to avoid
      symbol conflicts.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor: Move glamor_glyphs_init to create screen resources stage. · bf4cbbd4
      Zhigang Gong authored
      As in glamor_glyphs_init, we may need to create pixmap. Thus it must
      be called after the pixmap resources allocation. Just move it to
      screen resource creation stage is good enough for mow.
      Also introduce a macro GLAMOR_FOR_XORG to glamor.h. As glamor may
      be used by Xephyr which doesn't don't have those xorg header files
      and also don't need the egl extension.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Disable ALPHA8 fbo. · 5e7fdbb4
      Zhigang Gong authored
      As some platform doesn't support to use ALPHA8 texture as
      draw target, we have to disable it. It seems there is no
      easy way to check that.
      Signed-off-by: Zhigang Gong's avatarZhigang Gong <zhigang.gong@gmail.com>
    • Zhigang Gong's avatar
      glamor: Remove GLEW dependency. · 172e8cfc
      Zhigang Gong authored
      Glamor doesn't need to use GLEW. We can parse the extension by
      ourself. This patch also fix the fbo size checking from a hard
      coded style to a dynamic checking style.
      Signed-off-by: Zhigang Gong's avatarZhigang Gong <zhigang.gong@gmail.com>
    • Zhigang Gong's avatar
      glamor: Concentrate FBO's creation to one function. · d66bd971
      Zhigang Gong authored
      And add status checking for it.
      Signed-off-by: Zhigang Gong's avatarZhigang Gong <zhigang.gong@gmail.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor-es2: Fix some non-es2 functions. · 94d884a1
      Zhigang Gong authored
      ES2.0 doesn't support QUADS and also doesn't support
      some EXT APIs. Fix some of them in this commit.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor: Fix one bug for Xephyr. · 0ef1698b
      Zhigang Gong authored
      Xephyr doesn't has a bounded valid texture. It seems that we can't
      load texture 0 directly sometimes. Especially in the copyarea, function
      if that is the case, we prefer to use fbo blit to read the screen pixmap
      rather than load the bound texture.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Use small internal texture format if possible. · 9b667ffd
      Zhigang Gong authored
      Reduce some texture memory requirement and also save
      some bandwidth.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Implement delayed solid filling. · 5c4d53c5
      Zhigang Gong authored
      When we need to solid fill an entire pixmap with a specific color,
      we do not need to draw it immediately. We can defer it to the
      following occasions:
      1. The pixmap will be used as source, then we can just use a shader
         to instead of one copyarea.
      2. The pixmap will be used as target, then we can do the filling
         just before drawing new pixel onto it. The filling and drawing
         will have the same target texture, we can save one time of
         fbo context switching.
      Actually, for the 2nd case, we have opportunity to further optimize
      it. We can just fill the untouched region.
      By applying this patch, the cairo-trace for the firefox-planet-gnome's
      rendering time decrease to 14seconds from 16 seconds.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor: Add one option to force create a cpu memory pixmap. · 33c6c78a
      Zhigang Gong authored
      Some special case we want to get a cpu memory pixmap. For example
      to gather a large cpu memory pixmap's block to a small pixmap.
      Add pixmap's priviate data's deallocation when destroy a pixmap.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Don't map the vbo to system memory. · 8890b388
      Zhigang Gong authored
      Access mapped vbo address is too slow. And by use system memory
      directly, rgb10text/aa10text increases from 980K/1160K to 117K/140K.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Initialize pixmap private's container to correct value. · 489e6c4e
      Zhigang Gong authored
      When calling from ephyr, we forgot to initialize it to the correct
      value. Will cause segfault when run Xephyr.
      Signed-off-by: Zhigang Gong's avatarZhigang Gong <zhigang.gong@gmail.com>
    • Zhigang Gong's avatar
      glamor : Add dynamic texture uploading feature. · 355334fc
      Zhigang Gong authored
      Major refactoring.
      1. Rewrite the pixmap texture uploading and downloading functions.
         Add some new functions for both the prepare/finish access and
         the new performance feature dynamic texture uploading, which
         could download and upload the current image to/from a private
         texture/fbo. In the uploading or downloading phase, we need to
         handle two things:
         The first is the yInverted option, If it set, then we don't need
         to flip y. If not set, if it is from a dynamic texture uploading
         then we don't need to flip either if the current drawing process
         will flip it latter. If it is from finish_access, then we must
         flip the y axis.
         The second thing is the alpha channel hanlding, if the pixmap's
         format is something like x8a8r8g8, x1r5g5b5 which means it doesn't
         has alpha channel, but it do has those extra bits. Then we need to
         wire those bits to 1.
      2. Add almost all the required picture format support.
         This is not as trivial as it looks like. The previous implementation
         only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format,
         we have to fallback to cpu. The reason why we can't simply add those
         other color format is because the exists of picture. one drawable
         pixmap may has one or even more container pictures. The drawable pixmap's
         depth can't map to a specified color format, for example depth 16 can
         mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get
         get the color format just from the depth value. But the pixmap do not
         has a pict_format element. We have to make a new one in the pixmap
         private data structure. Reroute the CreatePicture to glamor_create_picture
         and then store the picture's format to the pixmap's private structure.
         This is not an ideal solution, as there may be more than one pictures
         refer to the same pixmap. Then we will have trouble. There is an example
         in glamor_composite_with_shader. The source and mask often share the
         same pixmap, but use different picture format. Our current solution is to
         combine those two different picture formats to one which will not lose any
         data. Then change the source's format to this new format and then upload
         the pixmap to texture once. It works. If we fail to find a matched new
         format then we fallback.
         There still is a potential problem, if two pictures refer to the same
         pixmap, and one of them destroy the picture, but the other still remained
         to be used latter. We don't handle that situation currently. To be fixed.
      3. Dynamic texture uploading.
         This is a performance feature. Although we don't like the client to hold
         a pixmap data to shared memory and we can't accelerate it. And even worse,
         we may need to fallback all the required pixmaps to cpu memory and then
         process them on CPU. This feature is to mitigate this penalty. When the
         target pixmap has a valid gl fbo attached to it. But the other pixmaps are
         not. Then it will be more efficient to upload the other pixmaps to GPU and
         then do the blitting or rendering on GPU than fallback all the pixmaps to CPU.
         To enable this feature, I experienced a significant performance improvement
         in the Game "Mines" :).
      4. Debug facility.
         Modify the debug output mechanism. Now add a new macro:
         glamor_debug_output(_level_, _format_,...) to conditional output some messages
         according to the environment variable GLAMOR_DEBUG. We have the following
         levels currently.
          exports GLAMOR_DEBUG to 3 will enable all the above messages.
      5. Changes in pixmap private data structure.
         Add some for the full color format supports and relate it to the pictures which
         already described. Also Add the following new elements:
         gl_fbo - to indicates whether this pixmap is on gpu only.
         gl_tex - to indicates whether the tex is valid and is containing the pixmap's
                  image originally.
         As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may
         also has a valid fbo or tex attached to it. So we will have to use the above
         new element to check it true type.
      After this commit, we can pass the rendercheck testing for all the picture formats.
      And is much much fater than fallback to cpu when doing rendercheck testing.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor: Add render triangles support. · 229240e5
      Zhigang Gong authored
      By default, fallback to frame buffer currently. This commit
      makes us pass the rendercheck's triangles testing.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Use software fb for 1bpp pixmap. · ac0589c9
      Zhigang Gong authored
      For 1bpp pixmap, software fb get better performance than
      GL surface. The main reason is that fbo doesn't support
      1bpp texture as internal format, so we have to translate
      a 1bpp bitmap to a 8bit alpha format each time which is
      very inefficient. And the previous implementation is
      not supported by the latest OpenGL 4.0, the GL_BITMAP
      was deprecated.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor: Don't use glamor_pixmap_type currently. · b8ce483f
      Zhigang Gong authored
      Added comments to glamor_pixmap_create. To be refined in the future.
      We need to identify whether a pixmap is a CPU memory pixmap or a
      GPU pixmap. Current implementation is not correct. There are three
      1. Too large pixmap, we direct it to CPU memory pixmap.
      2. w ==0 ||  h == 0 pixmap, this case has two possibilities:
         2.1 It will become a screen pixmap latter, then it should be
             GPU type.
         2.2 It's a scratch pixmap or created from a share memory, then
             it should belong to CPU memory.
      XXX, need to be refined latter.
    • Zhigang Gong's avatar
      glamor: Switch to software fb for too large pixmap. · f871d174
      Zhigang Gong authored
      If pixmap's size exceeds the limitation of the MESA library, the
      rendering will fail. So we switch to software fb if it is the case.
      Add one new element for pixmap private structure to indicate whehter
      we are a software fb type or a opengl type.