2008-12-17 00:14:31 +01:00
|
|
|
/*
|
|
|
|
|
* Copyright © 2008 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>
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
#ifndef GLAMOR_PRIV_H
|
|
|
|
|
#define GLAMOR_PRIV_H
|
|
|
|
|
|
2011-04-08 08:53:15 +02:00
|
|
|
#ifdef HAVE_DIX_CONFIG_H
|
|
|
|
|
#include <dix-config.h>
|
2011-08-02 09:54:15 +02:00
|
|
|
#include <xorg-config.h>
|
2011-04-08 08:53:15 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
2008-12-17 00:14:31 +01:00
|
|
|
#include "glamor.h"
|
2011-08-02 09:54:15 +02:00
|
|
|
|
2011-08-03 04:49:18 +02:00
|
|
|
#define GL_GLEXT_PROTOTYPES
|
2011-09-08 09:14:43 +02:00
|
|
|
|
2011-08-11 21:05:02 +02:00
|
|
|
#ifdef GLAMOR_GLES2
|
2011-08-03 04:49:18 +02:00
|
|
|
#include <GLES2/gl2.h>
|
|
|
|
|
#include <GLES2/gl2ext.h>
|
2011-08-23 08:04:07 +02:00
|
|
|
|
2011-09-08 09:14:43 +02:00
|
|
|
#define GLAMOR_DEFAULT_PRECISION "precision mediump float;\n"
|
|
|
|
|
#include "glamor_glext.h"
|
2011-08-03 04:49:18 +02:00
|
|
|
#else
|
2011-08-11 21:05:02 +02:00
|
|
|
#include <GL/gl.h>
|
|
|
|
|
#include <GL/glext.h>
|
2011-08-23 08:04:07 +02:00
|
|
|
#define GLAMOR_DEFAULT_PRECISION
|
2011-08-03 04:49:18 +02:00
|
|
|
#endif
|
|
|
|
|
|
2010-02-10 06:17:09 +01:00
|
|
|
#ifdef RENDER
|
|
|
|
|
#include "glyphstr.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
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
|
|
|
#include "glamor_debug.h"
|
|
|
|
|
|
2009-08-25 21:10:32 +02:00
|
|
|
typedef struct glamor_composite_shader {
|
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
|
|
|
GLuint prog;
|
|
|
|
|
GLint dest_to_dest_uniform_location;
|
|
|
|
|
GLint dest_to_source_uniform_location;
|
|
|
|
|
GLint dest_to_mask_uniform_location;
|
|
|
|
|
GLint source_uniform_location;
|
|
|
|
|
GLint mask_uniform_location;
|
2009-08-25 21:10:32 +02:00
|
|
|
} glamor_composite_shader;
|
|
|
|
|
|
2010-02-10 06:17:09 +01:00
|
|
|
typedef struct {
|
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
|
|
|
INT16 x_src;
|
|
|
|
|
INT16 y_src;
|
|
|
|
|
INT16 x_mask;
|
|
|
|
|
INT16 y_mask;
|
|
|
|
|
INT16 x_dst;
|
|
|
|
|
INT16 y_dst;
|
|
|
|
|
INT16 width;
|
|
|
|
|
INT16 height;
|
2010-02-10 06:17:09 +01:00
|
|
|
} glamor_composite_rect_t;
|
|
|
|
|
|
|
|
|
|
|
2011-08-03 10:52:19 +02:00
|
|
|
enum glamor_vertex_type {
|
|
|
|
|
GLAMOR_VERTEX_POS,
|
|
|
|
|
GLAMOR_VERTEX_SOURCE,
|
|
|
|
|
GLAMOR_VERTEX_MASK
|
|
|
|
|
};
|
|
|
|
|
|
2010-02-10 07:35:04 +01:00
|
|
|
enum shader_source {
|
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
|
|
|
SHADER_SOURCE_SOLID,
|
|
|
|
|
SHADER_SOURCE_TEXTURE,
|
|
|
|
|
SHADER_SOURCE_TEXTURE_ALPHA,
|
|
|
|
|
SHADER_SOURCE_COUNT,
|
2010-02-10 07:35:04 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum shader_mask {
|
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
|
|
|
SHADER_MASK_NONE,
|
|
|
|
|
SHADER_MASK_SOLID,
|
|
|
|
|
SHADER_MASK_TEXTURE,
|
|
|
|
|
SHADER_MASK_TEXTURE_ALPHA,
|
|
|
|
|
SHADER_MASK_COUNT,
|
2010-02-10 07:35:04 +01:00
|
|
|
};
|
|
|
|
|
|
2010-02-18 18:23:22 +01:00
|
|
|
enum shader_in {
|
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
|
|
|
SHADER_IN_SOURCE_ONLY,
|
|
|
|
|
SHADER_IN_NORMAL,
|
|
|
|
|
SHADER_IN_CA_SOURCE,
|
|
|
|
|
SHADER_IN_CA_ALPHA,
|
|
|
|
|
SHADER_IN_COUNT,
|
2010-02-18 18:23:22 +01:00
|
|
|
};
|
|
|
|
|
|
2011-07-20 07:06:23 +02:00
|
|
|
struct glamor_screen_private;
|
|
|
|
|
struct glamor_pixmap_private;
|
|
|
|
|
typedef void (*glamor_pixmap_validate_function_t)(struct glamor_screen_private*,
|
|
|
|
|
struct glamor_pixmap_private*);
|
2011-08-03 04:49:18 +02:00
|
|
|
|
|
|
|
|
enum glamor_gl_flavor {
|
|
|
|
|
GLAMOR_GL_DESKTOP, // OPENGL API
|
|
|
|
|
GLAMOR_GL_ES2 // OPENGL ES2.0 API
|
|
|
|
|
};
|
|
|
|
|
|
2011-06-30 10:01:57 +02:00
|
|
|
#define GLAMOR_CREATE_PIXMAP_CPU 0x100
|
2011-09-08 09:14:43 +02:00
|
|
|
|
|
|
|
|
#define GLAMOR_NUM_GLYPH_CACHES 4
|
|
|
|
|
#define GLAMOR_NUM_GLYPH_CACHE_FORMATS 2
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
PicturePtr picture; /* Where the glyphs of the cache are stored */
|
|
|
|
|
GlyphPtr *glyphs;
|
|
|
|
|
uint16_t count;
|
|
|
|
|
uint16_t evict;
|
|
|
|
|
} glamor_glyph_cache_t;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#include "glamor_gl_dispatch.h"
|
|
|
|
|
|
2008-12-17 00:14:31 +01:00
|
|
|
typedef struct glamor_screen_private {
|
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
|
|
|
CloseScreenProcPtr saved_close_screen;
|
|
|
|
|
CreateGCProcPtr saved_create_gc;
|
|
|
|
|
CreatePixmapProcPtr saved_create_pixmap;
|
|
|
|
|
DestroyPixmapProcPtr saved_destroy_pixmap;
|
|
|
|
|
GetSpansProcPtr saved_get_spans;
|
|
|
|
|
GetImageProcPtr saved_get_image;
|
|
|
|
|
CompositeProcPtr saved_composite;
|
|
|
|
|
TrapezoidsProcPtr saved_trapezoids;
|
|
|
|
|
GlyphsProcPtr saved_glyphs;
|
|
|
|
|
ChangeWindowAttributesProcPtr saved_change_window_attributes;
|
|
|
|
|
CopyWindowProcPtr saved_copy_window;
|
|
|
|
|
BitmapToRegionProcPtr saved_bitmap_to_region;
|
|
|
|
|
TrianglesProcPtr saved_triangles;
|
|
|
|
|
CreatePictureProcPtr saved_create_picture;
|
|
|
|
|
DestroyPictureProcPtr saved_destroy_picture;
|
2011-08-30 12:24:53 +02:00
|
|
|
UnrealizeGlyphProcPtr saved_unrealize_glyph;
|
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
|
|
|
|
|
|
|
|
int yInverted;
|
|
|
|
|
int screen_fbo;
|
|
|
|
|
GLuint vbo;
|
|
|
|
|
int vbo_offset;
|
|
|
|
|
int vbo_size;
|
|
|
|
|
char *vb;
|
|
|
|
|
int vb_stride;
|
2011-08-03 04:49:18 +02:00
|
|
|
enum glamor_gl_flavor gl_flavor;
|
2011-08-11 21:05:02 +02:00
|
|
|
int has_pack_invert;
|
|
|
|
|
int has_fbo_blit;
|
|
|
|
|
int max_fbo_size;
|
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
|
|
|
|
|
|
|
|
/* glamor_finishaccess */
|
2011-08-11 21:56:02 +02:00
|
|
|
GLint finish_access_prog[2];
|
2011-08-15 18:21:09 +02:00
|
|
|
GLint finish_access_no_revert[2];
|
|
|
|
|
GLint finish_access_swap_rb[2];
|
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
|
|
|
|
|
|
|
|
/* glamor_solid */
|
|
|
|
|
GLint solid_prog;
|
|
|
|
|
GLint solid_color_uniform_location;
|
|
|
|
|
|
|
|
|
|
/* glamor_tile */
|
|
|
|
|
GLint tile_prog;
|
|
|
|
|
|
|
|
|
|
/* glamor_putimage */
|
|
|
|
|
GLint put_image_xybitmap_prog;
|
|
|
|
|
GLint put_image_xybitmap_fg_uniform_location;
|
|
|
|
|
GLint put_image_xybitmap_bg_uniform_location;
|
|
|
|
|
|
|
|
|
|
/* glamor_composite */
|
|
|
|
|
glamor_composite_shader composite_shader[SHADER_SOURCE_COUNT]
|
|
|
|
|
[SHADER_MASK_COUNT]
|
|
|
|
|
[SHADER_IN_COUNT];
|
|
|
|
|
Bool has_source_coords, has_mask_coords;
|
|
|
|
|
int render_nr_verts;
|
2011-07-20 07:06:23 +02:00
|
|
|
glamor_pixmap_validate_function_t *pixmap_validate_funcs;
|
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
|
|
|
glamor_glyph_cache_t glyph_caches[GLAMOR_NUM_GLYPH_CACHES];
|
|
|
|
|
char delayed_fallback_string[GLAMOR_DELAYED_STRING_MAX + 1];
|
|
|
|
|
int delayed_fallback_pending;
|
2011-08-30 11:45:07 +02:00
|
|
|
|
|
|
|
|
glamor_glyph_cache_t glyphCaches[GLAMOR_NUM_GLYPH_CACHE_FORMATS];
|
|
|
|
|
Bool glyph_cache_initialized;
|
2011-09-08 08:05:46 +02:00
|
|
|
struct glamor_gl_dispatch dispatch;
|
2008-12-17 00:14:31 +01:00
|
|
|
} glamor_screen_private;
|
|
|
|
|
|
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
|
|
|
typedef enum glamor_access {
|
|
|
|
|
GLAMOR_ACCESS_RO,
|
|
|
|
|
GLAMOR_ACCESS_RW,
|
|
|
|
|
GLAMOR_ACCESS_WO,
|
|
|
|
|
} glamor_access_t;
|
|
|
|
|
|
2011-07-20 07:06:23 +02:00
|
|
|
enum _glamor_pending_op_type{
|
|
|
|
|
GLAMOR_PENDING_NONE,
|
|
|
|
|
GLAMOR_PENDING_FILL
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct _glamor_pending_fill {
|
|
|
|
|
unsigned int type;
|
|
|
|
|
GLfloat color4fv[4];
|
|
|
|
|
CARD32 colori;
|
|
|
|
|
} glamor_pending_fill;
|
|
|
|
|
|
|
|
|
|
typedef union _glamor_pending_op {
|
|
|
|
|
unsigned int type;
|
|
|
|
|
glamor_pending_fill fill;
|
|
|
|
|
} glamor_pending_op;
|
|
|
|
|
|
2011-09-08 09:14:43 +02:00
|
|
|
/*
|
|
|
|
|
* glamor_pixmap_private - glamor pixmap's private structure.
|
|
|
|
|
* @gl_fbo: The pixmap is attached to a fbo originally.
|
|
|
|
|
* @gl_tex: The pixmap is in a gl texture originally.
|
|
|
|
|
* @pbo_valid: The pbo has a valid copy of the pixmap's data.
|
|
|
|
|
* @is_picture: The drawable is attached to a picture.
|
|
|
|
|
* @tex: attached texture.
|
|
|
|
|
* @fb: attached fbo.
|
|
|
|
|
* @pbo: attached pbo.
|
|
|
|
|
* @access_mode: access mode during the prepare/finish pair.
|
|
|
|
|
* @pict_format: the corresponding picture's format.
|
|
|
|
|
* #pending_op: currently only support pending filling.
|
|
|
|
|
* @container: The corresponding pixmap's pointer.
|
|
|
|
|
**/
|
2011-07-20 07:06:23 +02:00
|
|
|
|
2009-08-21 00:28:13 +02:00
|
|
|
typedef struct glamor_pixmap_private {
|
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
|
|
|
unsigned char gl_fbo:1;
|
|
|
|
|
unsigned char gl_tex:1;
|
|
|
|
|
unsigned char pbo_valid:1;
|
|
|
|
|
unsigned char is_picture:1;
|
|
|
|
|
GLuint tex;
|
|
|
|
|
GLuint fb;
|
|
|
|
|
GLuint pbo;
|
|
|
|
|
glamor_access_t access_mode;
|
|
|
|
|
PictFormatShort pict_format;
|
2011-07-20 07:06:23 +02:00
|
|
|
glamor_pending_op pending_op;
|
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
|
|
|
PixmapPtr container;
|
2011-09-08 08:05:46 +02:00
|
|
|
glamor_screen_private *glamor_priv;
|
2009-08-21 00:28:13 +02:00
|
|
|
} glamor_pixmap_private;
|
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
|
* Pixmap dynamic status, used by dynamic upload feature.
|
|
|
|
|
*
|
|
|
|
|
* GLAMOR_NONE: initial status, don't need to do anything.
|
|
|
|
|
* GLAMOR_UPLOAD_PENDING: marked as need to be uploaded to gl texture.
|
|
|
|
|
* GLAMOR_UPLOAD_DONE: the pixmap has been uploaded successfully.
|
|
|
|
|
* GLAMOR_UPLOAD_FAILED: fail to upload the pixmap.
|
|
|
|
|
*
|
|
|
|
|
* */
|
|
|
|
|
typedef enum glamor_pixmap_status {
|
|
|
|
|
GLAMOR_NONE,
|
|
|
|
|
GLAMOR_UPLOAD_PENDING,
|
|
|
|
|
GLAMOR_UPLOAD_DONE,
|
|
|
|
|
GLAMOR_UPLOAD_FAILED
|
|
|
|
|
} glamor_pixmap_status_t;
|
|
|
|
|
|
|
|
|
|
|
2008-12-17 00:14:31 +01:00
|
|
|
extern DevPrivateKey glamor_screen_private_key;
|
2009-08-21 00:28:13 +02:00
|
|
|
extern DevPrivateKey glamor_pixmap_private_key;
|
2008-12-17 00:14:31 +01:00
|
|
|
static inline glamor_screen_private *
|
|
|
|
|
glamor_get_screen_private(ScreenPtr screen)
|
|
|
|
|
{
|
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
|
|
|
return (glamor_screen_private *)dixLookupPrivate(&screen->devPrivates,
|
|
|
|
|
glamor_screen_private_key);
|
2008-12-17 00:14:31 +01:00
|
|
|
}
|
2009-08-21 00:28:13 +02:00
|
|
|
static inline glamor_pixmap_private *
|
|
|
|
|
glamor_get_pixmap_private(PixmapPtr 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
|
|
|
return dixLookupPrivate(&pixmap->devPrivates, glamor_pixmap_private_key);
|
2009-08-21 00:28:13 +02:00
|
|
|
}
|
2008-12-17 00:14:31 +01:00
|
|
|
|
2010-02-18 01:00:22 +01:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* Returns TRUE if the given planemask covers all the significant bits in the
|
|
|
|
|
* pixel values for pDrawable.
|
|
|
|
|
*/
|
|
|
|
|
static inline Bool
|
|
|
|
|
glamor_pm_is_solid(DrawablePtr drawable, unsigned long planemask)
|
|
|
|
|
{
|
|
|
|
|
return (planemask & FbFullMask(drawable->depth)) ==
|
|
|
|
|
FbFullMask(drawable->depth);
|
2010-02-18 01:00:22 +01:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
extern int glamor_debug_level;
|
|
|
|
|
|
2008-12-17 00:14:31 +01:00
|
|
|
/* glamor.c */
|
|
|
|
|
PixmapPtr glamor_get_drawable_pixmap(DrawablePtr drawable);
|
|
|
|
|
|
2011-04-13 09:50:26 +02:00
|
|
|
Bool glamor_close_screen(int idx, ScreenPtr screen);
|
|
|
|
|
|
|
|
|
|
|
2009-09-05 03:43:02 +02:00
|
|
|
/* glamor_copyarea.c */
|
|
|
|
|
RegionPtr
|
|
|
|
|
glamor_copy_area(DrawablePtr src, DrawablePtr dst, GCPtr gc,
|
|
|
|
|
int srcx, int srcy, int width, int height, int dstx, int dsty);
|
2010-02-08 20:12:44 +01:00
|
|
|
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_copywindow.c */
|
|
|
|
|
void glamor_copy_window(WindowPtr win, DDXPointRec old_origin,
|
|
|
|
|
RegionPtr src_region);
|
|
|
|
|
|
2008-12-17 00:14:31 +01:00
|
|
|
/* glamor_core.c */
|
2009-09-22 21:08:19 +02:00
|
|
|
Bool glamor_prepare_access(DrawablePtr drawable, glamor_access_t access);
|
|
|
|
|
void glamor_finish_access(DrawablePtr drawable);
|
|
|
|
|
Bool glamor_prepare_access_window(WindowPtr window);
|
|
|
|
|
void glamor_finish_access_window(WindowPtr window);
|
2010-02-08 12:09:52 +01:00
|
|
|
Bool glamor_prepare_access_gc(GCPtr gc);
|
|
|
|
|
void glamor_finish_access_gc(GCPtr gc);
|
2010-02-08 14:40:06 +01:00
|
|
|
void glamor_init_finish_access_shaders(ScreenPtr screen);
|
2010-02-08 10:16:21 +01:00
|
|
|
const Bool glamor_get_drawable_location(const DrawablePtr drawable);
|
2010-02-11 22:21:47 +01:00
|
|
|
void glamor_get_drawable_deltas(DrawablePtr drawable, PixmapPtr pixmap,
|
|
|
|
|
int *x, int *y);
|
2008-12-17 00:14:31 +01:00
|
|
|
Bool glamor_create_gc(GCPtr gc);
|
2011-06-10 10:01:40 +02:00
|
|
|
Bool glamor_stipple(PixmapPtr pixmap, PixmapPtr stipple,
|
2008-12-20 22:43:52 +01:00
|
|
|
int x, int y, int width, int height,
|
|
|
|
|
unsigned char alu, unsigned long planemask,
|
|
|
|
|
unsigned long fg_pixel, unsigned long bg_pixel,
|
|
|
|
|
int stipple_x, int stipple_y);
|
2011-09-08 08:05:46 +02:00
|
|
|
GLint glamor_compile_glsl_prog(glamor_gl_dispatch *dispatch, GLenum type, const char *source);
|
|
|
|
|
void glamor_link_glsl_prog(glamor_gl_dispatch *dispatch, GLint prog);
|
2009-08-20 21:32:53 +02:00
|
|
|
void glamor_get_color_4f_from_pixel(PixmapPtr pixmap, unsigned long fg_pixel,
|
|
|
|
|
GLfloat *color);
|
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
|
|
|
|
|
|
|
|
int glamor_set_destination_pixmap(PixmapPtr pixmap);
|
|
|
|
|
int glamor_set_destination_pixmap_priv(glamor_pixmap_private *pixmap_priv);
|
|
|
|
|
|
|
|
|
|
/* nc means no check. caller must ensure this pixmap has valid fbo.
|
|
|
|
|
* usually use the GLAMOR_PIXMAP_PRIV_HAS_FBO firstly.
|
|
|
|
|
* */
|
|
|
|
|
void glamor_set_destination_pixmap_priv_nc(glamor_pixmap_private *pixmap_priv);
|
|
|
|
|
|
2011-08-15 18:21:09 +02:00
|
|
|
|
|
|
|
|
PixmapPtr
|
|
|
|
|
glamor_es2_pixmap_read_prepare(PixmapPtr source, GLenum *format,
|
|
|
|
|
GLenum *type, int no_alpha, int no_revert);
|
|
|
|
|
|
2011-09-08 08:05:46 +02:00
|
|
|
void glamor_set_alu(struct glamor_gl_dispatch * dispatch, unsigned char alu);
|
2009-08-24 17:59:52 +02:00
|
|
|
Bool glamor_set_planemask(PixmapPtr pixmap, unsigned long planemask);
|
2009-09-22 21:08:19 +02:00
|
|
|
Bool glamor_change_window_attributes(WindowPtr pWin, unsigned long mask);
|
|
|
|
|
RegionPtr glamor_bitmap_to_region(PixmapPtr pixmap);
|
2011-08-11 21:05:02 +02:00
|
|
|
Bool glamor_gl_has_extension(char *extension);
|
|
|
|
|
int glamor_gl_get_version(void);
|
|
|
|
|
|
|
|
|
|
#define GLAMOR_GL_VERSION_ENCODE(major, minor) ( \
|
|
|
|
|
((major) * 256) \
|
|
|
|
|
+ ((minor) * 1))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-20 22:43:52 +01:00
|
|
|
|
|
|
|
|
/* glamor_fill.c */
|
|
|
|
|
void glamor_fill(DrawablePtr drawable,
|
|
|
|
|
GCPtr gc,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
int width,
|
|
|
|
|
int height);
|
2011-06-10 10:01:40 +02:00
|
|
|
Bool glamor_solid(PixmapPtr pixmap, int x, int y, int width, int height,
|
2009-08-20 21:32:53 +02:00
|
|
|
unsigned char alu, unsigned long planemask,
|
|
|
|
|
unsigned long fg_pixel);
|
2009-08-21 01:06:42 +02:00
|
|
|
void glamor_solid_fail_region(PixmapPtr pixmap,
|
|
|
|
|
int x, int y, int width, int height);
|
2008-12-20 22:43:52 +01:00
|
|
|
|
|
|
|
|
/* glamor_fillspans.c */
|
|
|
|
|
void glamor_fill_spans(DrawablePtr drawable,
|
|
|
|
|
GCPtr gc,
|
|
|
|
|
int n,
|
|
|
|
|
DDXPointPtr points,
|
|
|
|
|
int *widths,
|
|
|
|
|
int sorted);
|
2008-12-17 00:14:31 +01:00
|
|
|
|
2009-08-20 21:32:53 +02:00
|
|
|
void glamor_init_solid_shader(ScreenPtr screen);
|
|
|
|
|
|
2009-08-20 23:43:43 +02:00
|
|
|
/* glamor_getspans.c */
|
|
|
|
|
void
|
|
|
|
|
glamor_get_spans(DrawablePtr drawable,
|
|
|
|
|
int wmax,
|
|
|
|
|
DDXPointPtr points,
|
|
|
|
|
int *widths,
|
|
|
|
|
int nspans,
|
|
|
|
|
char *dst_start);
|
|
|
|
|
|
2010-02-10 06:17:09 +01:00
|
|
|
/* glamor_glyphs.c */
|
|
|
|
|
void glamor_glyphs_fini(ScreenPtr screen);
|
|
|
|
|
void glamor_glyphs(CARD8 op,
|
|
|
|
|
PicturePtr pSrc,
|
|
|
|
|
PicturePtr pDst,
|
|
|
|
|
PictFormatPtr maskFormat,
|
|
|
|
|
INT16 xSrc,
|
|
|
|
|
INT16 ySrc, int nlist, GlyphListPtr list, GlyphPtr * glyphs);
|
|
|
|
|
|
2011-08-30 12:24:53 +02:00
|
|
|
void
|
|
|
|
|
glamor_glyph_unrealize (ScreenPtr screen, GlyphPtr glyph);
|
2009-08-24 17:03:17 +02:00
|
|
|
/* glamor_setspans.c */
|
|
|
|
|
void glamor_set_spans(DrawablePtr drawable, GCPtr gc, char *src,
|
|
|
|
|
DDXPointPtr points, int *widths, int n, int sorted);
|
|
|
|
|
|
2009-08-26 02:24:30 +02:00
|
|
|
/* glamor_polyfillrect.c */
|
|
|
|
|
void
|
|
|
|
|
glamor_poly_fill_rect(DrawablePtr drawable,
|
|
|
|
|
GCPtr gc,
|
|
|
|
|
int nrect,
|
|
|
|
|
xRectangle *prect);
|
|
|
|
|
|
2010-02-08 09:58:55 +01:00
|
|
|
/* glamor_polylines.c */
|
|
|
|
|
void
|
|
|
|
|
glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int mode, int n,
|
|
|
|
|
DDXPointPtr points);
|
|
|
|
|
|
2009-08-23 00:54:24 +02:00
|
|
|
/* glamor_putimage.c */
|
|
|
|
|
void
|
|
|
|
|
glamor_put_image(DrawablePtr drawable, GCPtr gc, int depth, int x, int y,
|
|
|
|
|
int w, int h, int leftPad, int format, char *bits);
|
2009-08-26 01:56:50 +02:00
|
|
|
void glamor_init_putimage_shaders(ScreenPtr screen);
|
2009-08-23 00:54:24 +02:00
|
|
|
|
2009-08-21 01:43:22 +02:00
|
|
|
/* glamor_render.c */
|
|
|
|
|
void glamor_composite(CARD8 op,
|
|
|
|
|
PicturePtr pSrc,
|
|
|
|
|
PicturePtr pMask,
|
|
|
|
|
PicturePtr pDst,
|
|
|
|
|
INT16 xSrc,
|
|
|
|
|
INT16 ySrc,
|
|
|
|
|
INT16 xMask,
|
|
|
|
|
INT16 yMask,
|
|
|
|
|
INT16 xDst,
|
|
|
|
|
INT16 yDst,
|
|
|
|
|
CARD16 width,
|
|
|
|
|
CARD16 height);
|
2009-08-21 19:02:02 +02:00
|
|
|
void glamor_trapezoids(CARD8 op,
|
|
|
|
|
PicturePtr src, PicturePtr dst,
|
|
|
|
|
PictFormatPtr mask_format, INT16 x_src, INT16 y_src,
|
|
|
|
|
int ntrap, xTrapezoid *traps);
|
2009-08-25 21:10:32 +02:00
|
|
|
void glamor_init_composite_shaders(ScreenPtr screen);
|
2010-02-10 06:17:09 +01:00
|
|
|
void glamor_composite_rects(CARD8 op,
|
2011-08-30 11:45:07 +02:00
|
|
|
PicturePtr src, PicturePtr mask, PicturePtr dst,
|
2010-02-10 06:17:09 +01:00
|
|
|
int nrect, glamor_composite_rect_t *rects);
|
2009-08-21 01:43:22 +02:00
|
|
|
|
2009-08-21 01:06:42 +02:00
|
|
|
/* glamor_tile.c */
|
2011-06-10 10:01:40 +02:00
|
|
|
Bool glamor_tile(PixmapPtr pixmap, PixmapPtr tile,
|
2009-08-21 01:06:42 +02:00
|
|
|
int x, int y, int width, int height,
|
|
|
|
|
unsigned char alu, unsigned long planemask,
|
|
|
|
|
int tile_x, int tile_y);
|
|
|
|
|
void glamor_init_tile_shader(ScreenPtr screen);
|
|
|
|
|
|
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
|
|
|
/* glamor_triangles.c */
|
2011-06-10 08:07:54 +02:00
|
|
|
void
|
|
|
|
|
glamor_triangles (CARD8 op,
|
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
|
|
|
PicturePtr pSrc,
|
|
|
|
|
PicturePtr pDst,
|
|
|
|
|
PictFormatPtr maskFormat,
|
|
|
|
|
INT16 xSrc,
|
|
|
|
|
INT16 ySrc,
|
|
|
|
|
int ntris,
|
|
|
|
|
xTriangle *tris);
|
|
|
|
|
|
|
|
|
|
/* glamor_pixmap.c */
|
|
|
|
|
|
2011-07-20 07:06:23 +02:00
|
|
|
void
|
|
|
|
|
glamor_pixmap_init(ScreenPtr screen);
|
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
|
|
|
/**
|
|
|
|
|
* Download a pixmap's texture to cpu memory. If success,
|
|
|
|
|
* One copy of current pixmap's texture will be put into
|
|
|
|
|
* the pixmap->devPrivate.ptr. Will use pbo to map to
|
|
|
|
|
* the pointer if possible.
|
|
|
|
|
* The pixmap must be a gl texture pixmap. gl_fbo and
|
|
|
|
|
* gl_tex must be 1. Used by glamor_prepare_access.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
Bool
|
|
|
|
|
glamor_download_pixmap_to_cpu(PixmapPtr pixmap, glamor_access_t access);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Restore a pixmap's data which is downloaded by
|
|
|
|
|
* glamor_download_pixmap_to_cpu to its original
|
|
|
|
|
* gl texture. Used by glamor_finish_access.
|
|
|
|
|
*
|
|
|
|
|
* The pixmap must be
|
|
|
|
|
* in texture originally. In other word, the gl_fbo
|
|
|
|
|
* must be 1.
|
|
|
|
|
**/
|
|
|
|
|
void
|
|
|
|
|
glamor_restore_pixmap_to_texture(PixmapPtr pixmap);
|
2011-08-11 15:54:28 +02:00
|
|
|
/**
|
|
|
|
|
* Ensure to have a fbo attached to the pixmap.
|
|
|
|
|
* If the pixmap already has one fbo then do nothing.
|
|
|
|
|
* Otherwise, it will generate a new fbo, and bind
|
|
|
|
|
* the pixmap's texture to the fbo.
|
|
|
|
|
* The pixmap must has a valid texture before call this
|
|
|
|
|
* API, othersie, it will trigger a assert.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
glamor_pixmap_ensure_fb(PixmapPtr 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
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Upload a pixmap to gl texture. Used by dynamic pixmap
|
|
|
|
|
* uploading feature. The pixmap must be a software pixmap.
|
|
|
|
|
* This function will change current FBO and current shaders.
|
|
|
|
|
*/
|
|
|
|
|
enum glamor_pixmap_status
|
|
|
|
|
glamor_upload_pixmap_to_texture(PixmapPtr pixmap);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Upload a picture to gl texture. Similar to the
|
|
|
|
|
* glamor_upload_pixmap_to_texture. Used in rendering.
|
|
|
|
|
**/
|
|
|
|
|
enum glamor_pixmap_status
|
|
|
|
|
glamor_upload_picture_to_texture(PicturePtr picture);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Destroy all the resources allocated on the uploading
|
|
|
|
|
* phase, includs the tex and fbo.
|
|
|
|
|
**/
|
|
|
|
|
void
|
|
|
|
|
glamor_destroy_upload_pixmap(PixmapPtr pixmap);
|
|
|
|
|
|
2011-07-20 07:06:23 +02:00
|
|
|
void
|
|
|
|
|
glamor_validate_pixmap(PixmapPtr 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
|
|
|
|
|
|
|
|
int
|
|
|
|
|
glamor_create_picture(PicturePtr picture);
|
|
|
|
|
|
|
|
|
|
Bool
|
|
|
|
|
glamor_prepare_access_picture(PicturePtr picture, glamor_access_t access);
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
glamor_finish_access_picture(PicturePtr picture);
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
glamor_destroy_picture(PicturePtr picture);
|
|
|
|
|
|
|
|
|
|
enum glamor_pixmap_status
|
|
|
|
|
glamor_upload_picture_to_texture(PicturePtr picture);
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
glamor_picture_format_fixup(PicturePtr picture, glamor_pixmap_private *pixmap_priv);
|
|
|
|
|
|
2011-09-08 09:14:43 +02:00
|
|
|
#include"glamor_utils.h"
|
|
|
|
|
|
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
|
|
|
/* Dynamic pixmap upload to texture if needed.
|
|
|
|
|
* Sometimes, the target is a gl texture pixmap/picture,
|
|
|
|
|
* but the source or mask is in cpu memory. In that case,
|
|
|
|
|
* upload the source/mask to gl texture and then avoid
|
|
|
|
|
* fallback the whole process to cpu. Most of the time,
|
|
|
|
|
* this will increase performance obviously. */
|
|
|
|
|
|
|
|
|
|
#define GLAMOR_PIXMAP_DYNAMIC_UPLOAD
|
2011-08-30 11:45:07 +02:00
|
|
|
#define GLAMOR_DELAYED_FILLING
|
2011-06-10 08:07:54 +02:00
|
|
|
|
2011-06-22 08:33:38 +02:00
|
|
|
|
|
|
|
|
|
2008-12-17 00:14:31 +01:00
|
|
|
#endif /* GLAMOR_PRIV_H */
|
