1. 18 Dec, 2013 5 commits
  2. 26 Sep, 2011 18 commits
    • 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: Unify the variable name which used to indicate no alpha. · 667d6553
      Zhigang Gong authored
      The original code use different name and the name is vague.
      Now change it to no_alpha.
      Signed-off-by: Zhigang Gong's avatarZhigang Gong <zhigang.gong@gmail.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
      glamor: Concentrate and reduce some coords processing code. · ca1908e1
      Zhigang Gong authored
      Concentrate the verties and texture coords processing code to a new
      file glamor_utils.h. Change most of the code to macro. Will have some
      performance benefit on slow machine. And reduce most of the duplicate
      code when calculate the normalized coords.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.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
      glamor: Silent compilation warnings due to some deprecated APIs. · c97d4533
      Zhigang Gong authored
      those xcalloc/xfree/xalloc/XNFprintf/... are deprecated. Replace
      then with the new one. And fix some other minor problems.
    • Zhigang Gong's avatar
      glamor: Add new feature which is to flip output on y axis. · eb3487a4
      Zhigang Gong authored
      Due to the coordinate system on EGL is different from FBO
      object. To support EGL surface well, we add this new feature.
      When calling glamor_init from EGL ddx driver, it should use
      the new flag GLAMOR_INVERTED_Y_AXIS.
    • Eric Anholt's avatar
      glamor: Fix and enable glamor_get_spans(). · b1f67a50
      Eric Anholt authored
      This makes running the cairo test suite almost tolerable.
    • Eric Anholt's avatar
      glamor: Fix screen_x/screen_y handling for compositing. · be82a062
      Eric Anholt authored
      It's not an offset from pixmap coords to composited pixmap coords,
      it's an offset from screen-relative window drawable coords to
      composited pixmap coords.
    • Eric Anholt's avatar
      glamor: All the fallbacks in the world. · d8d3fa10
      Eric Anholt authored
      Bringup is really not flying when I can't see anything.  So dump back
      to all software so I can turn on a bit at a time.
    • Eric Anholt's avatar
    • Eric Anholt's avatar
    • Eric Anholt's avatar
      glamor: Fix memory leak in getspans. · 0360ba36
      Eric Anholt authored
    • Eric Anholt's avatar
      glamor: Add 8bpp to get/setspans. · f66e5c41
      Eric Anholt authored
    • Eric Anholt's avatar
      glamor: Fill in 1 and 24-bit getspans. · 7500ee2b
      Eric Anholt authored
    • Eric Anholt's avatar
      glamor: Create FBOs for pixmaps. · 51910356
      Eric Anholt authored
    • Eric Anholt's avatar
      glamor: Add getspans implementation. · 4f139db9
      Eric Anholt authored
  3. 03 Dec, 2008 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Rework symbol visibility for easier maintenance · 49f77fff
      Paulo Cesar Pereira de Andrade authored
        Save in a few special cases, _X_EXPORT should not be used in C source
      files. Instead, it should be used in headers, and the proper C source
      include that header. Some special cases are symbols that need to be
      shared between modules, but not expected to be used by external drivers,
      and symbols that are accessible via LoaderSymbol/dlopen.
        This patch also adds conditionally some new sdk header files, depending
      on extensions enabled. These files were added to match pattern for
      other extensions/modules, that is, have the headers "deciding" symbol
      visibility in the sdk. These headers are:
      o Xext/panoramiXsrv.h, Xext/panoramiX.h
      o fbpict.h (unconditionally)
      o vidmodeproc.h
      o mioverlay.h (unconditionally, used only by xaa)
      o xfixes.h (unconditionally, symbols required by dri2)
        LoaderSymbol and similar functions now don't have different prototypes,
      in loaderProcs.h and xf86Module.h, so that both headers can be included,
      without the need of defining IN_LOADER.
        xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
      not exported (and with a comment about it).
  4. 25 Nov, 2008 2 commits
  5. 03 Oct, 2008 1 commit
  6. 18 Aug, 2008 1 commit
  7. 12 Mar, 2008 1 commit
    • Mark Kettenis's avatar
      OpenBSD support for libpciaccess. · 06c0372c
      Mark Kettenis authored
      xserver and libpciaccess both need to open /dev/xf86, which can only
      be opened once.  I implemented pci_system_init_dev_mem() like Ian
      suggested.  This requires some minor changes to the BSD-specific
      os-support code.  Since pci_system_init_dev_mem() is a no-op on
      FreeBSD this should be no problem.
  8. 28 Aug, 2007 1 commit
    • Eric Anholt's avatar
      Replace BSD custom PCI code with a stub implementation thanks to pciaccess. · adf46b57
      Eric Anholt authored
      Note that pciaccess doesn't yet have Net/OpenBSD support, but the relevant
      code should go there instead of disconnected code in the X Server.
      While here, remove the now-disabled INCLUDE_XF86_NO_DOMAIN from the headers,
      and un-disable xf8StdAccResFromOS for those OSes without domain support which
      will need it.
  9. 31 Jul, 2007 1 commit
  10. 01 Nov, 2006 1 commit
    • Daniel Stone's avatar
      input: add non-keyboard bell ringing function · 81728558
      Daniel Stone authored
      Add a generic 'ring the bell' function (console bell on Linux and BSD,
      /dev/audio on Solaris), and add DDX functions for this.  Make this the
      core keyboard's bell.
      Port Xvfb and Xnest to this.
      Port XFree86 to this, with OS-specific hooks for Linux, BSD, and Solaris
      taken from foo_io.c in the old layer.