andreacavalli
/
xserver-multidpi
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
xserver-multidpi/glamor/glamor_debug.h

79 lines
2.6 KiB
C
Raw Normal View History

Added some copyright and author information. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:13:47 +02:00
/*
* Copyright © 2009 Intel Corporation
* Copyright © 1998 Keith Packard
*
* 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:
* Zhigang Gong <zhigang.gong@gmail.com>
*
*/
glamor : Add dynamic texture uploading feature. Major refactoring. 1. Rewrite the pixmap texture uploading and downloading functions. Add some new functions for both the prepare/finish access and the new performance feature dynamic texture uploading, which could download and upload the current image to/from a private texture/fbo. In the uploading or downloading phase, we need to handle two things: The first is the yInverted option, If it set, then we don't need to flip y. If not set, if it is from a dynamic texture uploading then we don't need to flip either if the current drawing process will flip it latter. If it is from finish_access, then we must flip the y axis. The second thing is the alpha channel hanlding, if the pixmap's format is something like x8a8r8g8, x1r5g5b5 which means it doesn't has alpha channel, but it do has those extra bits. Then we need to wire those bits to 1. 2. Add almost all the required picture format support. This is not as trivial as it looks like. The previous implementation only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format, we have to fallback to cpu. The reason why we can't simply add those other color format is because the exists of picture. one drawable pixmap may has one or even more container pictures. The drawable pixmap's depth can't map to a specified color format, for example depth 16 can mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get get the color format just from the depth value. But the pixmap do not has a pict_format element. We have to make a new one in the pixmap private data structure. Reroute the CreatePicture to glamor_create_picture and then store the picture's format to the pixmap's private structure. This is not an ideal solution, as there may be more than one pictures refer to the same pixmap. Then we will have trouble. There is an example in glamor_composite_with_shader. The source and mask often share the same pixmap, but use different picture format. Our current solution is to combine those two different picture formats to one which will not lose any data. Then change the source's format to this new format and then upload the pixmap to texture once. It works. If we fail to find a matched new format then we fallback. There still is a potential problem, if two pictures refer to the same pixmap, and one of them destroy the picture, but the other still remained to be used latter. We don't handle that situation currently. To be fixed. 3. Dynamic texture uploading. This is a performance feature. Although we don't like the client to hold a pixmap data to shared memory and we can't accelerate it. And even worse, we may need to fallback all the required pixmaps to cpu memory and then process them on CPU. This feature is to mitigate this penalty. When the target pixmap has a valid gl fbo attached to it. But the other pixmaps are not. Then it will be more efficient to upload the other pixmaps to GPU and then do the blitting or rendering on GPU than fallback all the pixmaps to CPU. To enable this feature, I experienced a significant performance improvement in the Game "Mines" :). 4. Debug facility. Modify the debug output mechanism. Now add a new macro: glamor_debug_output(_level_, _format_,...) to conditional output some messages according to the environment variable GLAMOR_DEBUG. We have the following levels currently. exports GLAMOR_DEBUG to 3 will enable all the above messages. 5. Changes in pixmap private data structure. Add some for the full color format supports and relate it to the pictures which already described. Also Add the following new elements: gl_fbo - to indicates whether this pixmap is on gpu only. gl_tex - to indicates whether the tex is valid and is containing the pixmap's image originally. As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may also has a valid fbo or tex attached to it. So we will have to use the above new element to check it true type. After this commit, we can pass the rendercheck testing for all the picture formats. And is much much fater than fallback to cpu when doing rendercheck testing. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
#ifndef __GLAMOR_DEBUG_H__
#define __GLAMOR_DEBUG_H__
#define GLAMOR_DEBUG_NONE 0
glamor: Don't always fallback everything when change window attr. Change the glamor_change_window_attributes's handling. We don't need to fallback every thing to cpu at the beginning. Only when there is a real need to change the pixmap's format, we need to do something. Otherwise, we need do nothing here. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-22 12:15:02 +02:00
#define GLAMOR_DEBUG_UNIMPL 0
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
#define GLAMOR_DEBUG_FALLBACK 1
glamor: Don't always fallback everything when change window attr. Change the glamor_change_window_attributes's handling. We don't need to fallback every thing to cpu at the beginning. Only when there is a real need to change the pixmap's format, we need to do something. Otherwise, we need do nothing here. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-22 12:15:02 +02:00
#define GLAMOR_DEBUG_TEXTURE_DOWNLOAD 2
#define GLAMOR_DEBUG_TEXTURE_DYNAMIC_UPLOAD 3
extern void
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
AbortServer(void)
_X_NORETURN;
glamor: Don't always fallback everything when change window attr. Change the glamor_change_window_attributes's handling. We don't need to fallback every thing to cpu at the beginning. Only when there is a real need to change the pixmap's format, we need to do something. Otherwise, we need do nothing here. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-22 12:15:02 +02:00
#define GLAMOR_PANIC(_format_, ...) \
do { \
LogMessageVerb(X_NONE, 0, "Glamor Fatal Error" \
" at %32s line %d: " _format_ "\n", \
__FUNCTION__, __LINE__, \
##__VA_ARGS__ ); \
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
exit(1); \
glamor: Don't always fallback everything when change window attr. Change the glamor_change_window_attributes's handling. We don't need to fallback every thing to cpu at the beginning. Only when there is a real need to change the pixmap's format, we need to do something. Otherwise, we need do nothing here. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-22 12:15:02 +02:00
} while(0)
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +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
#define __debug_output_message(_format_, _prefix_, ...) \
LogMessageVerb(X_NONE, 0, \
"%32s:\t" _format_ , \
/*_prefix_,*/ \
__FUNCTION__, \
##__VA_ARGS__)
#define glamor_debug_output(_level_, _format_,...) \
do { \
if (glamor_debug_level >= _level_) \
__debug_output_message(_format_, \
"Glamor debug", \
##__VA_ARGS__); \
} while(0)
#define glamor_fallback(_format_,...) \
do { \
if (glamor_debug_level >= GLAMOR_DEBUG_FALLBACK) \
__debug_output_message(_format_, \
"Glamor fallback", \
##__VA_ARGS__);} while(0)
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
#define DEBUGF(str, ...) do {} while(0)
glamor_fbo: Introduce glamor fbo to manage all the fb/tex. This is the first patch to implement a fbo/tex pool mechanism which is like the sna's BO cache list. We firstly need to decopule the fbo/tex from each pixmap. The new glamor_pixmap_fbo data structure is for that purpose. It's somehow independent to each pixmap and can be reused latter by other pixmaps once it's detached from the current pixmap. And this commit also slightly change the way to create a memory pixmap. We will not create a pixmap private data structure by default, instead we will crete that structure when a memory pixmap is attaching a fbo to it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-18 12:21:36 +01:00
//#define DEBUGF(str, ...) ErrorF(str, ##__VA_ARGS__)
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
#define DEBUGRegionPrint(x) do {} while (0)
//#define DEBUGRegionPrint RegionPrint
glamor_fbo: Introduce glamor fbo to manage all the fb/tex. This is the first patch to implement a fbo/tex pool mechanism which is like the sna's BO cache list. We firstly need to decopule the fbo/tex from each pixmap. The new glamor_pixmap_fbo data structure is for that purpose. It's somehow independent to each pixmap and can be reused latter by other pixmaps once it's detached from the current pixmap. And this commit also slightly change the way to create a memory pixmap. We will not create a pixmap private data structure by default, instead we will crete that structure when a memory pixmap is attaching a fbo to it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-18 12:21:36 +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
#endif