1. 18 Dec, 2013 16 commits
    • 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
      glamor_eglmodule: Change module name according to normalize naming rule. · 1817b6c0
      Zhigang Gong authored
      As Xorg module loader will normalize module name which will
      remove '_' when we put "glamor_egl" to the configure file,
      then it will fail to find us.
      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-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_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
      Added more drawing functions. · 92643353
      Zhigang Gong authored
      As we want to take over all the possible GC ops from the DDX
      layer, we need to add all the missed functions.
      This commit also fixed one bug at polylines.
      We simply drop the bugy optimized code now, as it did not
      consider of clip info.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Export glamor_validate_gc to DDX. · c65dc686
      Zhigang Gong authored
      This is also a function which may direct access pixmaps which
      may be a glamor only pixmap and DDX doesn't know how to access
      it. We have to export this API to DDX driver and let the DDX
      driver use it to do the validation.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Add a new API glamor_create_gc. · b36d264e
      Zhigang Gong authored
      As at ValidateGC stage, it may need to touch the pixmap directly, for
      example the tile pixmap. We must export this interface to DDX driver
      and let the DDX driver to route the processing to us. As this pixmap
      may be a texture only pixmap, and DDX don't know how to handle it.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Export glamor_create_texture to DDX driver. · 5769d860
      Zhigang Gong authored
      If DDX failed to create textured pixmap from its BO's handle,
      it can turn to call this API to create a brand new glamor
      rather than fallback to pure in memory pixmap.
      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
      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>
    • Zhigang Gong's avatar
      Add new version glamor_poly_fill_rect without internal fallback. · 9b6a484d
      Zhigang Gong authored
      If need fallback, this new version just returns FALSE without
      doing anything. It's the caller's responsibility to implement
      fallback method.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      Add new version glamor_fillspans without internal fallback. · ba1b3b53
      Zhigang Gong authored
      For the purpose of incrementally intergration of existing intel
      driver, for the GC operations we may don't want to use glamor's
      internal fallback which is in general much slower than the
      implementation in intel driver. If the parameter "fallback" is
      false when call the glamor_fillspans, then if glamor found it
      can't accelerate it then it will just return a FALSE rather than
      fallback to a slow path.
      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 12 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
      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: Change glamor_egl_init API. · ae38bd7c
      Zhigang Gong authored
      Slightly change the API glamor_egl_init,
      as this initialization is to initialize the display not
      the screen, we should call it in xxx_preinit rather
      than xxxScreenInit(). we change the input parameter as
      below, as in preInit, the screen may not be allocated
      at all. And in glamor_egl_init, it will not call
      glamor_init. Driver should call glamor_init at
      screen_init stage.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor-egl: Move EGL surfaceless related code to dix module. · 60f14d60
      Zhigang Gong authored
      The functions in glamor_egl.c could be shared by any egl back
      end drivers.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
    • Zhigang Gong's avatar
      glamor-dix: Make a glamor dix module. · 65812b53
      Zhigang Gong authored
      And modify the header file to export three APIs to the
      ddx driver.
      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
    • 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.
    • Zhigang Gong's avatar
    • Eric Anholt's avatar
    • Eric Anholt's avatar
      More ephyr/glamor glue. · da6e0ffa
      Eric Anholt authored
    • Eric Anholt's avatar
      Add build infrastructure for glamor. · 0ec823ce
      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. 31 Jul, 2007 3 commits
  5. 06 Dec, 2006 1 commit
  6. 21 Jul, 2006 1 commit
    • Daniel Stone's avatar
      add basic D-BUS configuration mechanism · 02a95311
      Daniel Stone authored
      Also move LookupDeviceIntRec into the DIX, and add InputOption type, and
      NewInputDeviceRequest prototype (DIX requests DDX to add a device).  Does not
      link without an implemented NIDR.