diff options
author | Zhigang Gong <zhigang.gong@linux.intel.com> | 2012-02-10 16:04:07 +0800 |
---|---|---|
committer | Eric Anholt <eric@anholt.net> | 2013-12-18 11:23:48 -0800 |
commit | 430bc16ca03b3ea00255a4045c8e9fd11aea95ad (patch) | |
tree | 1b3eddda6b246f4df504d6aa170eb5ef68045e2b /glamor/glamor_polylines.c | |
parent | 0a8fb8563f3cecf2019d3a35d5a61ec2b3a069cd (diff) |
GLX: Enable glx support.
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"
EndSection
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: Zhigang Gong <zhigang.gong@linux.intel.com>
Diffstat (limited to 'glamor/glamor_polylines.c')
-rw-r--r-- | glamor/glamor_polylines.c | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/glamor/glamor_polylines.c b/glamor/glamor_polylines.c index 0217e8fcb..0d37a1dd1 100644 --- a/glamor/glamor_polylines.c +++ b/glamor/glamor_polylines.c @@ -49,6 +49,9 @@ _glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int mode, int n, xRectangle *rects; int x1, x2, y1, y2; int i; + glamor_screen_private *glamor_priv; + GLAMOR_DEFINE_CONTEXT; + /* Don't try to do wide lines or non-solid fill style. */ if (gc->lineWidth != 0) { /* This ends up in miSetSpans, which is accelerated as well as we @@ -108,6 +111,8 @@ _glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int mode, int n, && glamor_ddx_fallback_check_gc(gc)) return FALSE; + glamor_priv = glamor_get_screen_private(drawable->pScreen); + GLAMOR_SET_CONTEXT(glamor_priv); if (gc->lineWidth == 0) { if (glamor_prepare_access(drawable, GLAMOR_ACCESS_RW)) { if (glamor_prepare_access_gc(gc)) { @@ -121,6 +126,7 @@ wide_line: /* fb calls mi functions in the lineWidth != 0 case. */ fbPolyLine(drawable, gc, mode, n, points); } + GLAMOR_RESTORE_CONTEXT(glamor_priv); return TRUE; } |