2009-08-20 23:43:43 +02:00
|
|
|
/*
|
|
|
|
* Copyright © 2009 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Eric Anholt <eric@anholt.net>
|
2012-04-28 08:13:47 +02:00
|
|
|
* Zhigang Gong <zhigang.gong@linux.intel.com>
|
2009-08-20 23:43:43 +02:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "glamor_priv.h"
|
|
|
|
|
2011-12-13 15:48:34 +01:00
|
|
|
static Bool
|
|
|
|
_glamor_get_spans(DrawablePtr drawable,
|
|
|
|
int wmax,
|
|
|
|
DDXPointPtr points, int *widths, int count, char *dst,
|
|
|
|
Bool fallback)
|
2009-08-20 23:43:43 +02:00
|
|
|
{
|
2011-11-02 06:44:50 +01:00
|
|
|
PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable);
|
|
|
|
glamor_pixmap_private *pixmap_priv =
|
|
|
|
glamor_get_pixmap_private(pixmap);
|
|
|
|
int i;
|
|
|
|
uint8_t *readpixels_dst = (uint8_t *) dst;
|
2012-04-15 17:16:51 +02:00
|
|
|
void *data;
|
2011-11-02 06:44:50 +01:00
|
|
|
int x_off, y_off;
|
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;
|
2011-06-22 08:33:38 +02:00
|
|
|
|
2012-04-15 17:16:51 +02:00
|
|
|
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
|
2011-11-02 06:44:50 +01:00
|
|
|
goto fail;
|
2011-08-15 18:32:57 +02:00
|
|
|
|
2011-11-02 06:44:50 +01:00
|
|
|
glamor_get_drawable_deltas(drawable, pixmap, &x_off, &y_off);
|
|
|
|
for (i = 0; i < count; i++) {
|
2012-04-15 17:16:51 +02:00
|
|
|
data = glamor_download_sub_pixmap_to_cpu(pixmap, points[i].x + x_off,
|
|
|
|
points[i].y + y_off, widths[i], 1,
|
|
|
|
PixmapBytePad(widths[i], drawable->depth),
|
|
|
|
readpixels_dst, 0, GLAMOR_ACCESS_RO);
|
|
|
|
assert(data == readpixels_dst);
|
|
|
|
readpixels_dst += PixmapBytePad(widths[i], drawable->depth);
|
2011-05-11 19:08:38 +02:00
|
|
|
}
|
2010-02-08 13:15:38 +01:00
|
|
|
|
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:
|
2011-12-13 15:48:34 +01:00
|
|
|
|
|
|
|
if (!fallback
|
|
|
|
&& glamor_ddx_fallback_check_pixmap(drawable))
|
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
|
|
|
goto done;
|
|
|
|
|
gles2: Fixed color conversion for the formats except 1555 and 2101010.
This patch fixed two major problems when we do the color convesion with
GLES2.
1. lack of necessary formats in FBO pool.
GLES2 has three different possible texture formats, GL_RGBA,
GL_BGRA and GL_ALPHA. Previous implementation only has one bucket
for all the three formats which may reuse a incorrect texture format
when do the cache lookup. After this fix, we can enable fbo safely
when running with GLES2.
2. Refine the format matching method in
glamor_get_tex_format_type_from_pictformat.
If both revertion and swap_rb are needed, for example use GL_RGBA
to represent PICT_b8g8r8a8. Then the downloading and uploading should
be handled differently.
The picture's format is PICT_b8g8r8a8,
Then the expecting color layout is as below (little endian):
0 1 2 3 : address
a r g b
Now the in GLES2 the supported color format is GL_RGBA, type is
GL_UNSIGNED_TYPE, then we need to shuffle the fragment
color as :
frag_color = sample(texture).argb;
before we use glReadPixel to get it back.
For the uploading process, the shuffle is a revert shuffle.
We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color
to a texture, then let's see
0 1 2 3 : address
a r g b : correct colors
R G B A : GL_RGBA with GL_UNSIGNED_BYTE
Now we need to shuffle again, the mapping rule is
r = G, g = B, b = A, a = R. Then the uploading shuffle is as
below:
frag_color = sample(texture).gbar;
After this commit, gles2 version can pass render check with all
the formats except those 1555/2101010.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 15:53:44 +02:00
|
|
|
ret = TRUE;
|
2011-11-02 06:44:50 +01:00
|
|
|
if (glamor_prepare_access(drawable, GLAMOR_ACCESS_RO)) {
|
|
|
|
fbGetSpans(drawable, wmax, points, widths, count, dst);
|
2011-12-10 19:26:15 +01:00
|
|
|
glamor_finish_access(drawable, GLAMOR_ACCESS_RO);
|
2011-11-02 06:44:50 +01:00
|
|
|
}
|
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
|
|
|
done:
|
|
|
|
return ret;
|
2009-08-20 23:43:43 +02:00
|
|
|
}
|
2011-12-09 08:58:19 +01:00
|
|
|
|
2011-12-13 15:48:34 +01:00
|
|
|
void
|
|
|
|
glamor_get_spans(DrawablePtr drawable,
|
|
|
|
int wmax,
|
|
|
|
DDXPointPtr points, int *widths, int count, char *dst)
|
|
|
|
{
|
|
|
|
_glamor_get_spans(drawable, wmax, points,
|
|
|
|
widths, count, dst, TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
Bool
|
|
|
|
glamor_get_spans_nf(DrawablePtr drawable,
|
|
|
|
int wmax,
|
|
|
|
DDXPointPtr points, int *widths, int count, char *dst)
|
|
|
|
{
|
|
|
|
return _glamor_get_spans(drawable, wmax, points,
|
|
|
|
widths, count, dst, FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|