xserver-multidpi/glamor/glamor_copyarea.c

482 lines
13 KiB
C
Raw Normal View History

/*
* Copyright © 2008 Intel Corporation
* Copyright © 1998 Keith Packard
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of Keith Packard not be used in
* advertising or publicity pertaining to distribution of the software without
* specific, written prior permission. Keith Packard makes no
* representations about the suitability of this software for any purpose. It
* is provided "as is" without express or implied warranty.
*
* KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
* EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*
* Authors:
* Eric Anholt <eric@anholt.net>
* Zhigang Gong <zhigang.gong@linux.intel.com>
*/
#include "glamor_priv.h"
/** @file glamor_copyarea.c
*
* GC CopyArea implementation
*/
#ifndef GLAMOR_GLES2
static Bool
glamor_copy_n_to_n_fbo_blit(DrawablePtr src,
DrawablePtr dst,
GCPtr gc, BoxPtr box, int nbox, int dx, int dy)
{
ScreenPtr screen = dst->pScreen;
PixmapPtr dst_pixmap = glamor_get_drawable_pixmap(dst);
PixmapPtr src_pixmap = glamor_get_drawable_pixmap(src);
glamor_pixmap_private *src_pixmap_priv;
glamor_screen_private *glamor_priv =
glamor_get_screen_private(screen);
glamor_gl_dispatch *dispatch;
int dst_x_off, dst_y_off, src_x_off, src_y_off, i;
if (!glamor_priv->has_fbo_blit) {
glamor_delayed_fallback(screen,
"no EXT_framebuffer_blit\n");
return FALSE;
}
src_pixmap_priv = glamor_get_pixmap_private(src_pixmap);
if (gc) {
if (gc->alu != GXcopy) {
glamor_delayed_fallback(screen, "non-copy ALU\n");
return FALSE;
}
if (!glamor_pm_is_solid(dst, gc->planemask)) {
glamor_delayed_fallback(screen,
"non-solid planemask\n");
return FALSE;
}
}
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(src_pixmap_priv)) {
glamor_delayed_fallback(screen, "no src fbo\n");
return FALSE;
}
if (glamor_set_destination_pixmap(dst_pixmap))
return FALSE;
dispatch = glamor_get_dispatch(glamor_priv);
dispatch->glBindFramebuffer(GL_READ_FRAMEBUFFER_EXT,
src_pixmap_priv->fbo->fb);
glamor_get_drawable_deltas(dst, dst_pixmap, &dst_x_off,
&dst_y_off);
glamor_get_drawable_deltas(src, src_pixmap, &src_x_off,
&src_y_off);
src_y_off += dy;
for (i = 0; i < nbox; i++) {
if (glamor_priv->yInverted) {
dispatch->glBlitFramebuffer((box[i].x1 + dx +
src_x_off),
(box[i].y1 +
src_y_off),
(box[i].x2 + dx +
src_x_off),
(box[i].y2 +
src_y_off),
(box[i].x1 +
dst_x_off),
(box[i].y1 +
dst_y_off),
(box[i].x2 +
dst_x_off),
(box[i].y2 +
dst_y_off),
GL_COLOR_BUFFER_BIT,
GL_NEAREST);
} else {
int flip_dst_y1 =
dst_pixmap->drawable.height - (box[i].y2 +
dst_y_off);
int flip_dst_y2 =
dst_pixmap->drawable.height - (box[i].y1 +
dst_y_off);
int flip_src_y1 =
src_pixmap->drawable.height - (box[i].y2 +
src_y_off);
int flip_src_y2 =
src_pixmap->drawable.height - (box[i].y1 +
src_y_off);
dispatch->glBlitFramebuffer(box[i].x1 + dx +
src_x_off,
flip_src_y1,
box[i].x2 + dx +
src_x_off,
flip_src_y2,
box[i].x1 +
dst_x_off,
flip_dst_y1,
box[i].x2 +
dst_x_off,
flip_dst_y2,
GL_COLOR_BUFFER_BIT,
GL_NEAREST);
}
}
glamor_put_dispatch(glamor_priv);
return TRUE;
}
#endif
static Bool
glamor_copy_n_to_n_textured(DrawablePtr src,
DrawablePtr dst,
GCPtr gc, BoxPtr box, int nbox, int dx, int dy)
{
glamor_screen_private *glamor_priv =
glamor_get_screen_private(dst->pScreen);
glamor_gl_dispatch *dispatch;
PixmapPtr src_pixmap = glamor_get_drawable_pixmap(src);
PixmapPtr dst_pixmap = glamor_get_drawable_pixmap(dst);
int i;
float vertices[8], texcoords[8];
glamor_pixmap_private *src_pixmap_priv;
glamor_pixmap_private *dst_pixmap_priv;
int src_x_off, src_y_off, dst_x_off, dst_y_off;
enum glamor_pixmap_status src_status = GLAMOR_NONE;
GLfloat dst_xscale, dst_yscale, src_xscale, src_yscale;
int alu = GXcopy;
src_pixmap_priv = glamor_get_pixmap_private(src_pixmap);
dst_pixmap_priv = glamor_get_pixmap_private(dst_pixmap);
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(dst_pixmap_priv)) {
glamor_delayed_fallback(dst->pScreen, "dst has no fbo.\n");
return FALSE;
}
if (!src_pixmap_priv || !src_pixmap_priv->gl_fbo) {
glamor : Add dynamic texture uploading feature. 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: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
#ifndef GLAMOR_PIXMAP_DYNAMIC_UPLOAD
glamor_delayed_fallback(dst->pScreen, "src has no fbo.\n");
return FALSE;
glamor : Add dynamic texture uploading feature. 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: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
#else
src_status = glamor_upload_pixmap_to_texture(src_pixmap);
if (src_status != GLAMOR_UPLOAD_DONE)
return FALSE;
src_pixmap_priv = glamor_get_pixmap_private(src_pixmap);
glamor : Add dynamic texture uploading feature. 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: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
#endif
}
if (gc) {
if (!glamor_set_planemask(dst_pixmap, gc->planemask))
return FALSE;
alu = gc->alu;
}
pixmap_priv_get_scale(dst_pixmap_priv, &dst_xscale, &dst_yscale);
pixmap_priv_get_scale(src_pixmap_priv, &src_xscale, &src_yscale);
glamor_get_drawable_deltas(dst, dst_pixmap, &dst_x_off,
&dst_y_off);
dispatch = glamor_get_dispatch(glamor_priv);
if (!glamor_set_alu(dispatch, alu)) {
glamor_put_dispatch(glamor_priv);
return FALSE;
}
glamor_set_destination_pixmap_priv_nc(dst_pixmap_priv);
dispatch->glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT,
GL_FALSE, 2 * sizeof(float),
vertices);
dispatch->glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
glamor_get_drawable_deltas(src, src_pixmap, &src_x_off,
&src_y_off);
dx += src_x_off;
dy += src_y_off;
pixmap_priv_get_scale(src_pixmap_priv, &src_xscale,
&src_yscale);
dispatch->glActiveTexture(GL_TEXTURE0);
dispatch->glBindTexture(GL_TEXTURE_2D,
src_pixmap_priv->fbo->tex);
#ifndef GLAMOR_GLES2
dispatch->glEnable(GL_TEXTURE_2D);
dispatch->glTexParameteri(GL_TEXTURE_2D,
GL_TEXTURE_WRAP_S,
GL_CLAMP_TO_BORDER);
dispatch->glTexParameteri(GL_TEXTURE_2D,
GL_TEXTURE_WRAP_T,
GL_CLAMP_TO_BORDER);
#endif
dispatch->glTexParameteri(GL_TEXTURE_2D,
GL_TEXTURE_MIN_FILTER,
GL_NEAREST);
dispatch->glTexParameteri(GL_TEXTURE_2D,
GL_TEXTURE_MAG_FILTER,
GL_NEAREST);
dispatch->glVertexAttribPointer(GLAMOR_VERTEX_SOURCE, 2,
GL_FLOAT, GL_FALSE,
2 * sizeof(float),
texcoords);
dispatch->glEnableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
dispatch->glUseProgram(glamor_priv->finish_access_prog[0]);
dispatch->glUniform1i(glamor_priv->finish_access_revert[0],
REVERT_NONE);
dispatch->glUniform1i(glamor_priv->finish_access_swap_rb[0],
SWAP_NONE_UPLOADING);
for (i = 0; i < nbox; i++) {
glamor_set_normalize_vcoords(dst_xscale, dst_yscale,
box[i].x1 + dst_x_off,
box[i].y1 + dst_y_off,
box[i].x2 + dst_x_off,
box[i].y2 + dst_y_off,
glamor_priv->yInverted,
vertices);
glamor_set_normalize_tcoords(src_xscale,
src_yscale,
box[i].x1 + dx,
box[i].y1 + dy,
box[i].x2 + dx,
box[i].y2 + dy,
glamor_priv->yInverted,
texcoords);
dispatch->glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
}
dispatch->glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
dispatch->glDisableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
#ifndef GLAMOR_GLES2
dispatch->glDisable(GL_TEXTURE_2D);
#endif
dispatch->glUseProgram(0);
/* The source texture is bound to a fbo, we have to flush it here. */
glamor_put_dispatch(glamor_priv);
return TRUE;
}
static Bool
_glamor_copy_n_to_n(DrawablePtr src,
DrawablePtr dst,
GCPtr gc,
BoxPtr box,
int nbox,
int dx,
int dy,
Bool reverse,
Bool upsidedown, Pixel bitplane,
void *closure, Bool fallback)
{
glamor_access_t dst_access;
PixmapPtr dst_pixmap, src_pixmap, temp_pixmap = NULL;
DrawablePtr temp_src = src;
glamor_pixmap_private *dst_pixmap_priv, *src_pixmap_priv;
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>
2012-02-10 09:04:07 +01:00
glamor_screen_private *glamor_priv;
BoxRec bound;
ScreenPtr screen;
int temp_dx = dx;
int temp_dy = dy;
int src_x_off, src_y_off, dst_x_off, dst_y_off;
int i;
int overlaped = 0;
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>
2012-02-10 09:04:07 +01:00
Bool ret = FALSE;
if (nbox == 0)
return TRUE;
dst_pixmap = glamor_get_drawable_pixmap(dst);
dst_pixmap_priv = glamor_get_pixmap_private(dst_pixmap);
src_pixmap = glamor_get_drawable_pixmap(src);
src_pixmap_priv = glamor_get_pixmap_private(src_pixmap);
screen = dst_pixmap->drawable.pScreen;
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>
2012-02-10 09:04:07 +01:00
glamor_priv = glamor_get_screen_private(dst->pScreen);
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(dst_pixmap_priv)) {
glamor_fallback("dest pixmap %p has no fbo. \n",
dst_pixmap);
goto fail;
}
if (!src_pixmap_priv) {
glamor_set_pixmap_type(src_pixmap, GLAMOR_MEMORY);
src_pixmap_priv = glamor_get_pixmap_private(src_pixmap);
}
glamor_get_drawable_deltas(src, src_pixmap, &src_x_off,
&src_y_off);
glamor_get_drawable_deltas(dst, dst_pixmap, &dst_x_off,
&dst_y_off);
if (src_pixmap_priv->fbo && src_pixmap_priv->fbo->fb == dst_pixmap_priv->fbo->fb) {
int x_shift = abs(src_x_off - dx - dst_x_off);
int y_shift = abs(src_y_off - dy - dst_y_off);
for (i = 0; i < nbox; i++) {
if (x_shift < abs(box[i].x2 - box[i].x1)
&& y_shift < abs(box[i].y2 - box[i].y1)) {
overlaped = 1;
break;
}
}
}
#ifndef GLAMOR_GLES2
if ((overlaped
|| !src_pixmap_priv->gl_tex || !dst_pixmap_priv->gl_tex)
&& glamor_copy_n_to_n_fbo_blit(src, dst, gc, box, nbox, dx,
dy)) {
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>
2012-02-10 09:04:07 +01:00
ret = TRUE;
goto done;
}
#endif
glamor_calculate_boxes_bound(&bound, box, nbox);
/* Overlaped indicate the src and dst are the same pixmap. */
if (overlaped || (!GLAMOR_PIXMAP_PRIV_HAS_FBO(src_pixmap_priv)
&& ((bound.x2 - bound.x1) * (bound.y2 - bound.y1)
* 4 >
src_pixmap->drawable.width *
src_pixmap->drawable.height))) {
temp_pixmap = glamor_create_pixmap(screen,
bound.x2 - bound.x1,
bound.y2 - bound.y1,
src_pixmap->
drawable.depth,
overlaped ? 0 :
GLAMOR_CREATE_PIXMAP_CPU);
if (!temp_pixmap)
goto fail;
glamor_transform_boxes(box, nbox, -bound.x1, -bound.y1);
temp_src = &temp_pixmap->drawable;
if (overlaped)
glamor_copy_n_to_n_textured(src, temp_src, gc, box,
nbox,
temp_dx + bound.x1,
temp_dy + bound.y1);
else
fbCopyNtoN(src, temp_src, gc, box, nbox,
temp_dx + bound.x1, temp_dy + bound.y1,
reverse, upsidedown, bitplane, closure);
glamor_transform_boxes(box, nbox, bound.x1, bound.y1);
temp_dx = -bound.x1;
temp_dy = -bound.y1;
} else {
temp_dx = dx;
temp_dy = dy;
temp_src = src;
}
if (glamor_copy_n_to_n_textured
(temp_src, dst, gc, box, nbox, temp_dx, temp_dy)) {
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>
2012-02-10 09:04:07 +01:00
ret = TRUE;
goto done;
}
fail:
if (!fallback
&& glamor_ddx_fallback_check_pixmap(src)
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>
2012-02-10 09:04:07 +01:00
&& glamor_ddx_fallback_check_pixmap(dst))
goto done;
if (src_pixmap_priv->type == GLAMOR_DRM_ONLY
|| dst_pixmap_priv->type == GLAMOR_DRM_ONLY) {
LogMessage(X_WARNING,
"Access a DRM only pixmap is not allowed within glamor.\n");
return TRUE;
}
glamor_report_delayed_fallbacks(src->pScreen);
glamor_report_delayed_fallbacks(dst->pScreen);
glamor_fallback("from %p to %p (%c,%c)\n", src, dst,
glamor_get_drawable_location(src),
glamor_get_drawable_location(dst));
if (gc && gc->alu != GXcopy)
dst_access = GLAMOR_ACCESS_RW;
else
dst_access = GLAMOR_ACCESS_WO;
if (glamor_prepare_access(dst, GLAMOR_ACCESS_RW)) {
if (dst == src
|| glamor_prepare_access(src, GLAMOR_ACCESS_RO)) {
fbCopyNtoN(src, dst, gc, box, nbox,
dx, dy, reverse, upsidedown, bitplane,
closure);
if (dst != src)
glamor_finish_access(src, GLAMOR_ACCESS_RO);
}
glamor_finish_access(dst, GLAMOR_ACCESS_RW);
}
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>
2012-02-10 09:04:07 +01:00
ret = TRUE;
done:
glamor_clear_delayed_fallbacks(src->pScreen);
glamor_clear_delayed_fallbacks(dst->pScreen);
if (temp_src != src)
glamor_destroy_pixmap(temp_pixmap);
return ret;
}
RegionPtr
glamor_copy_area(DrawablePtr src, DrawablePtr dst, GCPtr gc,
int srcx, int srcy, int width, int height, int dstx,
int dsty)
{
RegionPtr region;
region = miDoCopy(src, dst, gc,
srcx, srcy, width, height,
dstx, dsty, glamor_copy_n_to_n, 0, NULL);
return region;
}
void
glamor_copy_n_to_n(DrawablePtr src,
DrawablePtr dst,
GCPtr gc,
BoxPtr box,
int nbox,
int dx,
int dy,
Bool reverse,
Bool upsidedown, Pixel bitplane,
void *closure)
{
_glamor_copy_n_to_n(src, dst, gc, box, nbox, dx,
dy, reverse, upsidedown, bitplane, closure, TRUE);
}
Bool
glamor_copy_n_to_n_nf(DrawablePtr src,
DrawablePtr dst,
GCPtr gc,
BoxPtr box,
int nbox,
int dx,
int dy,
Bool reverse,
Bool upsidedown, Pixel bitplane,
void *closure)
{
return _glamor_copy_n_to_n(src, dst, gc, box, nbox, dx,
dy, reverse, upsidedown, bitplane, closure, FALSE);
}