PLEASE NOTE: Glamor has been merged into Xorg server 1.16 (released July 2014)

As a result, portions of this page may no longer apply.

What is Glamor?

The glamor module is an open-source 2D graphics common driver for the X Window System as implemented by It supports a variety of graphics chipsets which have OpenGL/EGL/GBM supports.

It’s a GL-based rendering acceleration library for X server:

  • It uses GL functions and shader to complete the 2D graphics operations.
  • It uses normal texture to represent a drawable pixmap if possible.
  • It calls GL functions to render to the texture directly. It’s somehow hardware independent. And could be a building block of any X server’s DDX driver:

  • Xorg’s DDX driver could leverage glamor-egl package to create an egl context without any native X system. The xf86-video-modesetting driver uses glamor by default but other drivers have support for it (xf86-video-ati and xf86-video-intel). This package can support every platform which has OpenGL and gbm and drm libraries.

Why Glamor?

Basically, the biggest two advantages of Glamor are:

  1. Graphics device has powerful 3D capability. To use 3D function to accelerate 2D rendering is possible and many drivers already do so. OpenGL provides a more convenient and standard interface to leverage graphics device’s 3D power. It would be better to call OpenGL directly rather than manually write 3D pipeline control code for each different graphics device.
  2. We have heard of complains about why we need to develop two version drivers for a single graphics device for a long time. One is for mesa’s DRI driver and the other is for 2D DDX driver. One of glamor’s purpose is to eliminate the latter one.

How Glamor Works?

In Xorg, upper layer should always use low level DDX functions to handle rendering and never access a drawable directly. The common logic of the DDX is: setup appropriate 2D or 3D pipeline according to the rendering request and draw and render it directly, which will prepare a serial of hardware dependent command, and then upload the command to the graphics device through DRM interface, and if it failed or the feature is not implemented, DDX will map the drawable to a virtual memory buffer and then use fb functions to draw and render it using software.

Glamor has similar logic, but replace the 2D or 3D pipeline setup with GL's pipeline. In most case, pixmap and window have a normal texture object. When doing the render or draw process, the texture object will be binded to a frame buffer object, so all the subsequent draw and render operations can use GL functions or use the according shader. We do not need to setup pipeline and write the control code for each different graphics device, the GL will handle it. If that GL kind render can not complete because of failure or not support, Glamor will fallback to software rendering, which will use FB functions and upload it then if needs. This process needs memory copy several times and is relative slower, so the fallback cases should be decrease to the minimum.

Glamor now is implemented to be embedded in other DDX driver(By now, just xf86-video-intel support) to complete the draw and render functions. In the feature, Glamor will also be implemented as a seperated DDX driver.

How to Enable Glamor on Intel?

To enable Glamor, the following steps are needed:

  1. Rebuild the mesa using the parameter: --with-egl-platforms=x11,drm --with-gallium-drivers= --enable-gbm --enable-shared-glapi --enable-glx-tls.
  2. Rebuild the xf86-video-intel driver, add parameter --enable-glamor to enable glamor module which is embedded in intel driver.
  3. Build and install glamor source. The Glamor source can be get at git://
  4. Make sure you have the xorg configure file named glamor.conf at conf/glamor.conf under the directory /usr/share/X11/xorg.conf.d or /etc/X11/xorg.conf.d/. Although make install will try to install that file to the correct directory. But it may failed, as if you are installing the xserver to a local directory, then the "make install" will install glamor.conf to your local directory rather than the two system directories. So you may need to manually copy the file to the system's configuration directory. Otherwise, you will encounter segfault when start the xserver. Here is the content of the glamor.conf.

    Section "Module" 
        Load "dri2" 
        Load "glamoregl" 
    Section "Device" 
        Identifier "intel" 
        Driver "intel" 
        Option "AccelMethod" "glamor" 

    The reason why we need to load dri2/glamoregl earlier is both glx-xserver and glamor are a dri2 loader. And glx-xserver side has a own glapi/dispatch table implementation which is a subset of the standard mesa's implementation. So if the glx module is loaded earlier than dri2/glamoregl, then we will get an incomplete dispatch table and everything is broken in glamor then. This is also why we need to add --enable-glx-tls parameters when build mesa, as we need to keep mesa align with Xserver's behavious, xserver will enable-glx-tls by default, but mesa will not.

After you finish all the above steps, then you can try to start x with glamor enabled DDX. To make sure it's glamor running, you can refer to Xorg.0.log, and check that Glamor is enabled if you can find the log like: intel(0): Use GLAMOR acceleration.


version 0.5

Here are the new features in version 0.5:

  1. Support tiling large pixmap to multiple small textures.
  2. Enable gradient shader.
  3. Optimize glyphs rendering performance
  4. Implement first shader to generate trapezoids. Cairo-demo’s spinner on a large picture(12000x12000) get about 10x improvement, and gradient also get about 2x improvement. Aa10text and rgb10text also get about 2x improvement.


  1. Fix the coexisting problem with glx for latest xserver. Don’t rely on the module loading sequence.
  2. Continue performance tuning: 1. Implement delay flushing mechanism to avoid tiny drawing operation for each ?DrawElements/DrawArrays call. 1. Implement atlas for small pixmap. 1. Optimize trapezoid shader to reduce the overhead for those non-edge pixels. 1. Optimize trapezoid/gradient shader to merge the mask/source creation and compositing into one shader. 1. Optimize glamor itself’ overhead.
  3. Xv support.


Glamor has a restriction with latest xserver. The main issue is that glamor rely on the module loading sequence which is not guaranteed by current xserver. We will fix this issue in next version. If you want to try a full functional xserver with glamor, it’s recommended to use the following xserver version:

  • commit a615b90cab7569fae9d123e4da1d3373c871d84b Author: Keith Packard <> Date: Wed Mar 14 11:32:36 2012 -0700 * Bump version number to Now that 1.12 has branched, reset the version on master to a development number. * Signed-off-by: Keith Packard

version 0.4

Here are the new features in version 0.4:

  1. DRI2 now works well, and texture-from-pixmap also works well.
  2. Fully support glx including AIGLX, indirect glx's GL context coexists with glamor's GL context safely. Thanks for Chris Wilson's help to refine this function.
  3. Optimize most of the fallback path and avoid whole pixmap downloading/uploading as much as possible.
  4. 1BPP picture uploading now will not fallback the whole rendering path.
  5. Fully support all color formats for GLES2 port. Thanks for Lipeng's contribution and testing for the GLES2 port on PVR545 platform. And thanks Zhengyu to fix some PVR releated problems.
  6. Fixed many of the bugs for cairo-test-suite, now we get almost identical or even better result than UXA.
  7. Implemented a fbo/texture cache pool mechanism which will reduce the over head of texture/fbo destruction and creation, and bring overall 15-20% performance imprvoement. On PVR545 platform, we even get about 10x performance improvement with this feature.


We plan to release next version 0.5 at early of June. And the following major features will be added:

  1. Fully gradient optimization including linear and radial. Actually, the code is already in this release, but as it has some bugs and we disable it currently. Will fix those bug and enable it at next release.
  2. Large pixmap support. Currently, mesa only support 8Kx8K texture size, if a pixmap has larger size, we have to store it in main memory and is not efficient. This feature will tile a large pixmap to a texture array.
  3. Fully trapezoid optimization. Currently, the trapezoid rendering is not optimized, and it will call pixman to do the rasterization and then call glamor_composite to do the following composition, and then many texture uploading overhead is triggered there.
  4. Fine tune the fbo cache mechanism.


Glamor is managed in git. Please See

To get at the code, you can run:

  • git clone git:// For general information about using git, visit

Mailing List

All Glamor discussion is currently on You can join the mail list at If you met any problem with using this driver, please feel free to send email to this list, and I will help you to solve them.