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

192 lines
5.0 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 © 2001 Keith Packard
* 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>
* Zhigang Gong <zhigang.gong@linux.intel.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
#include <stdlib.h>
#include "glamor_priv.h"
/**
* Sets the offsets to add to coordinates to make them address the same bits in
* the backing drawable. These coordinates are nonzero only for redirected
* windows.
*/
void
glamor_get_drawable_deltas(DrawablePtr drawable, PixmapPtr pixmap,
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
int *x, int *y)
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
{
#ifdef COMPOSITE
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
if (drawable->type == DRAWABLE_WINDOW) {
*x = -pixmap->screen_x;
*y = -pixmap->screen_y;
return;
}
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
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
*x = 0;
*y = 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
}
glamor: Implement delayed solid filling. When we need to solid fill an entire pixmap with a specific color, we do not need to draw it immediately. We can defer it to the following occasions: 1. The pixmap will be used as source, then we can just use a shader to instead of one copyarea. 2. The pixmap will be used as target, then we can do the filling just before drawing new pixel onto it. The filling and drawing will have the same target texture, we can save one time of fbo context switching. Actually, for the 2nd case, we have opportunity to further optimize it. We can just fill the untouched region. By applying this patch, the cairo-trace for the firefox-planet-gnome's rendering time decrease to 14seconds from 16 seconds. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-07-20 07:06:23 +02:00
void
glamor_pixmap_init(ScreenPtr screen)
{
glamor-fbo-pool: Implement fbo cache mechanism. We classify the cache according to the texture's format/width/height. As openGL doesn't allow us to change a texture's format/width/height after the internal texture object is already allocated, we can't just calculate the size and then according ths size to put the fbo to an bucket which is just like SNA does. We can only put the fbo to the corresponding format/width/height bucket. This commit only support the exact size match. The following patch will remove this restriction, just need to handle the repeat/tile case when the size is not exactly match. Should use fls instead of ffs when decide the width/height bucket, thanks for Chris to point this out. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-19 13:47:55 +01:00
glamor: Implement delayed solid filling. When we need to solid fill an entire pixmap with a specific color, we do not need to draw it immediately. We can defer it to the following occasions: 1. The pixmap will be used as source, then we can just use a shader to instead of one copyarea. 2. The pixmap will be used as target, then we can do the filling just before drawing new pixel onto it. The filling and drawing will have the same target texture, we can save one time of fbo context switching. Actually, for the 2nd case, we have opportunity to further optimize it. We can just fill the untouched region. By applying this patch, the cairo-trace for the firefox-planet-gnome's rendering time decrease to 14seconds from 16 seconds. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-07-20 07:06:23 +02:00
}
glamor-fbo-pool: Implement fbo cache mechanism. We classify the cache according to the texture's format/width/height. As openGL doesn't allow us to change a texture's format/width/height after the internal texture object is already allocated, we can't just calculate the size and then according ths size to put the fbo to an bucket which is just like SNA does. We can only put the fbo to the corresponding format/width/height bucket. This commit only support the exact size match. The following patch will remove this restriction, just need to handle the repeat/tile case when the size is not exactly match. Should use fls instead of ffs when decide the width/height bucket, thanks for Chris to point this out. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-19 13:47:55 +01:00
void
glamor_pixmap_fini(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
void
glamor: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
glamor_set_destination_pixmap_fbo(glamor_screen_private *glamor_priv,
glamor_pixmap_fbo *fbo, int x0, int y0,
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
int width, int height)
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: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
glamor_make_current(glamor_priv);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glBindFramebuffer(GL_FRAMEBUFFER, fbo->fb);
glViewport(x0, y0, width, height);
gles2: Fixed color conversion for the formats except 1555 and 2101010. This patch fixed two major problems when we do the color convesion with GLES2. 1. lack of necessary formats in FBO pool. GLES2 has three different possible texture formats, GL_RGBA, GL_BGRA and GL_ALPHA. Previous implementation only has one bucket for all the three formats which may reuse a incorrect texture format when do the cache lookup. After this fix, we can enable fbo safely when running with GLES2. 2. Refine the format matching method in glamor_get_tex_format_type_from_pictformat. If both revertion and swap_rb are needed, for example use GL_RGBA to represent PICT_b8g8r8a8. Then the downloading and uploading should be handled differently. The picture's format is PICT_b8g8r8a8, Then the expecting color layout is as below (little endian): 0 1 2 3 : address a r g b Now the in GLES2 the supported color format is GL_RGBA, type is GL_UNSIGNED_TYPE, then we need to shuffle the fragment color as : frag_color = sample(texture).argb; before we use glReadPixel to get it back. For the uploading process, the shuffle is a revert shuffle. We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color to a texture, then let's see 0 1 2 3 : address a r g b : correct colors R G B A : GL_RGBA with GL_UNSIGNED_BYTE Now we need to shuffle again, the mapping rule is r = G, g = B, b = A, a = R. Then the uploading shuffle is as below: frag_color = sample(texture).gbar; After this commit, gles2 version can pass render check with all the formats except those 1555/2101010. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 15:53:44 +02:00
}
glamor: Implement delayed solid filling. When we need to solid fill an entire pixmap with a specific color, we do not need to draw it immediately. We can defer it to the following occasions: 1. The pixmap will be used as source, then we can just use a shader to instead of one copyarea. 2. The pixmap will be used as target, then we can do the filling just before drawing new pixel onto it. The filling and drawing will have the same target texture, we can save one time of fbo context switching. Actually, for the 2nd case, we have opportunity to further optimize it. We can just fill the untouched region. By applying this patch, the cairo-trace for the firefox-planet-gnome's rendering time decrease to 14seconds from 16 seconds. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-07-20 07:06:23 +02:00
gles2: Fixed color conversion for the formats except 1555 and 2101010. This patch fixed two major problems when we do the color convesion with GLES2. 1. lack of necessary formats in FBO pool. GLES2 has three different possible texture formats, GL_RGBA, GL_BGRA and GL_ALPHA. Previous implementation only has one bucket for all the three formats which may reuse a incorrect texture format when do the cache lookup. After this fix, we can enable fbo safely when running with GLES2. 2. Refine the format matching method in glamor_get_tex_format_type_from_pictformat. If both revertion and swap_rb are needed, for example use GL_RGBA to represent PICT_b8g8r8a8. Then the downloading and uploading should be handled differently. The picture's format is PICT_b8g8r8a8, Then the expecting color layout is as below (little endian): 0 1 2 3 : address a r g b Now the in GLES2 the supported color format is GL_RGBA, type is GL_UNSIGNED_TYPE, then we need to shuffle the fragment color as : frag_color = sample(texture).argb; before we use glReadPixel to get it back. For the uploading process, the shuffle is a revert shuffle. We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color to a texture, then let's see 0 1 2 3 : address a r g b : correct colors R G B A : GL_RGBA with GL_UNSIGNED_BYTE Now we need to shuffle again, the mapping rule is r = G, g = B, b = A, a = R. Then the uploading shuffle is as below: frag_color = sample(texture).gbar; After this commit, gles2 version can pass render check with all the formats except those 1555/2101010. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 15:53:44 +02:00
void
glamor: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
glamor_set_destination_pixmap_priv_nc(glamor_screen_private *glamor_priv,
PixmapPtr pixmap,
glamor_pixmap_private *pixmap_priv)
gles2: Fixed color conversion for the formats except 1555 and 2101010. This patch fixed two major problems when we do the color convesion with GLES2. 1. lack of necessary formats in FBO pool. GLES2 has three different possible texture formats, GL_RGBA, GL_BGRA and GL_ALPHA. Previous implementation only has one bucket for all the three formats which may reuse a incorrect texture format when do the cache lookup. After this fix, we can enable fbo safely when running with GLES2. 2. Refine the format matching method in glamor_get_tex_format_type_from_pictformat. If both revertion and swap_rb are needed, for example use GL_RGBA to represent PICT_b8g8r8a8. Then the downloading and uploading should be handled differently. The picture's format is PICT_b8g8r8a8, Then the expecting color layout is as below (little endian): 0 1 2 3 : address a r g b Now the in GLES2 the supported color format is GL_RGBA, type is GL_UNSIGNED_TYPE, then we need to shuffle the fragment color as : frag_color = sample(texture).argb; before we use glReadPixel to get it back. For the uploading process, the shuffle is a revert shuffle. We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color to a texture, then let's see 0 1 2 3 : address a r g b : correct colors R G B A : GL_RGBA with GL_UNSIGNED_BYTE Now we need to shuffle again, the mapping rule is r = G, g = B, b = A, a = R. Then the uploading shuffle is as below: frag_color = sample(texture).gbar; After this commit, gles2 version can pass render check with all the formats except those 1555/2101010. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 15:53:44 +02:00
{
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
int w, h;
largepixmap: Implement infrastructure for large pixmap. Added infrastructure for largepixmap, this commit implemented: 1. Create/Destroy large pixmap. 2. Upload/Download large pixmap. 3. Implement basic repeat normal support. 3. tile/fill/copyarea large pixmap get supported. The most complicated part glamor_composite still not implemented. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:52:14 +02:00
glamor: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
PIXMAP_PRIV_GET_ACTUAL_SIZE(pixmap, pixmap_priv, w, h);
glamor: Eliminate separate 'large' pixmap private structure Just embed the large elements in the regular pixmap private and collapse the union to a single struct. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 07:08:57 +01:00
glamor_set_destination_pixmap_fbo(glamor_priv, pixmap_priv->fbo, 0, 0, w, 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
}
int
glamor: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
glamor_set_destination_pixmap_priv(glamor_screen_private *glamor_priv,
PixmapPtr pixmap,
glamor_pixmap_private *pixmap_priv)
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: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
return -1;
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: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
glamor_set_destination_pixmap_priv_nc(glamor_priv, pixmap, pixmap_priv);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
return 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
}
int
glamor_set_destination_pixmap(PixmapPtr pixmap)
{
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
int err;
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
glamor: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
ScreenPtr screen = pixmap->drawable.pScreen;
glamor_screen_private *glamor_priv = glamor_get_screen_private(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: Remove screen private and pixmap ptrs from pixmap private and fbo There's no reason to waste memory storing redundant copies of the same pointer all over the system; just pass in pointers as necessary to each function. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-30 06:50:53 +01:00
err = glamor_set_destination_pixmap_priv(glamor_priv, pixmap, pixmap_priv);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
return err;
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
}
Bool
glamor: Pass depth to glamor_pm_is_solid and glamor_set_planemask Instead of passing the destination drawable, just pass the depth, as the underlying functions need only that to check whether the planemask is going to work. This API change will allow higher level functions to not need the destination pixmap. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-13 21:32:27 +02:00
glamor_set_planemask(int depth, unsigned long planemask)
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: Pass depth to glamor_pm_is_solid and glamor_set_planemask Instead of passing the destination drawable, just pass the depth, as the underlying functions need only that to check whether the planemask is going to work. This API change will allow higher level functions to not need the destination pixmap. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-10-13 21:32:27 +02:00
if (glamor_pm_is_solid(depth, planemask)) {
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
return GL_TRUE;
}
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: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
glamor_fallback("unsupported planemask %lx\n", planemask);
return GL_FALSE;
glamor : Add dynamic texture uploading feature. Major refactoring. 1. Rewrite the pixmap texture uploading and downloading functions. Add some new functions for both the prepare/finish access and the new performance feature dynamic texture uploading, which could download and upload the current image to/from a private texture/fbo. In the uploading or downloading phase, we need to handle two things: The first is the yInverted option, If it set, then we don't need to flip y. If not set, if it is from a dynamic texture uploading then we don't need to flip either if the current drawing process will flip it latter. If it is from finish_access, then we must flip the y axis. The second thing is the alpha channel hanlding, if the pixmap's format is something like x8a8r8g8, x1r5g5b5 which means it doesn't has alpha channel, but it do has those extra bits. Then we need to wire those bits to 1. 2. Add almost all the required picture format support. This is not as trivial as it looks like. The previous implementation only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format, we have to fallback to cpu. The reason why we can't simply add those other color format is because the exists of picture. one drawable pixmap may has one or even more container pictures. The drawable pixmap's depth can't map to a specified color format, for example depth 16 can mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get get the color format just from the depth value. But the pixmap do not has a pict_format element. We have to make a new one in the pixmap private data structure. Reroute the CreatePicture to glamor_create_picture and then store the picture's format to the pixmap's private structure. This is not an ideal solution, as there may be more than one pictures refer to the same pixmap. Then we will have trouble. There is an example in glamor_composite_with_shader. The source and mask often share the same pixmap, but use different picture format. Our current solution is to combine those two different picture formats to one which will not lose any data. Then change the source's format to this new format and then upload the pixmap to texture once. It works. If we fail to find a matched new format then we fallback. There still is a potential problem, if two pictures refer to the same pixmap, and one of them destroy the picture, but the other still remained to be used latter. We don't handle that situation currently. To be fixed. 3. Dynamic texture uploading. This is a performance feature. Although we don't like the client to hold a pixmap data to shared memory and we can't accelerate it. And even worse, we may need to fallback all the required pixmaps to cpu memory and then process them on CPU. This feature is to mitigate this penalty. When the target pixmap has a valid gl fbo attached to it. But the other pixmaps are not. Then it will be more efficient to upload the other pixmaps to GPU and then do the blitting or rendering on GPU than fallback all the pixmaps to CPU. To enable this feature, I experienced a significant performance improvement in the Game "Mines" :). 4. Debug facility. Modify the debug output mechanism. Now add a new macro: glamor_debug_output(_level_, _format_,...) to conditional output some messages according to the environment variable GLAMOR_DEBUG. We have the following levels currently. exports GLAMOR_DEBUG to 3 will enable all the above messages. 5. Changes in pixmap private data structure. Add some for the full color format supports and relate it to the pictures which already described. Also Add the following new elements: gl_fbo - to indicates whether this pixmap is on gpu only. gl_tex - to indicates whether the tex is valid and is containing the pixmap's image originally. As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may also has a valid fbo or tex attached to it. So we will have to use the above new element to check it true type. After this commit, we can pass the rendercheck testing for all the picture formats. And is much much fater than fallback to cpu when doing rendercheck testing. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
}
glamor_set_alu: Fallback for non GXcopy ops with GLES2. As GLES2 doesn't support LogiOps, we have to fallback here. GLES2 programing guide's statement is as below: "In addition, LogicOp is removed as it is very infrequently used by applications and the OpenGL ES working group did not get requests from independent software vendors (ISVs) to support this feature in OpenGL ES 2.0." So, I think, fallback here may not a big deal ;). Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-06 05:02:36 +02:00
Bool
glamor: Add a screen argument to drop an ifdef from glamor_set_alu(). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2013-12-27 10:17:10 +01:00
glamor_set_alu(ScreenPtr screen, unsigned char alu)
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: Add a screen argument to drop an ifdef from glamor_set_alu(). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2013-12-27 10:17:10 +01:00
glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
glamor: Switch the gl_flavor to a boolean is_gles. There are only 2 flavors we are distinguishing -- GL versions are handled separately. Signed-off-by: Eric Anholt <eric@anholt.net>
2019-03-26 23:02:38 +01:00
if (glamor_priv->is_gles) {
glamor: Add a screen argument to drop an ifdef from glamor_set_alu(). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2013-12-27 10:17:10 +01:00
if (alu != GXcopy)
return FALSE;
else
return TRUE;
}
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
if (alu == GXcopy) {
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glDisable(GL_COLOR_LOGIC_OP);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
return TRUE;
}
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glEnable(GL_COLOR_LOGIC_OP);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
switch (alu) {
case GXclear:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_CLEAR);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXand:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_AND);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXandReverse:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_AND_REVERSE);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXandInverted:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_AND_INVERTED);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXnoop:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_NOOP);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXxor:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_XOR);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXor:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_OR);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXnor:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_NOR);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXequiv:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_EQUIV);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXinvert:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_INVERT);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXorReverse:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_OR_REVERSE);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXcopyInverted:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_COPY_INVERTED);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXorInverted:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_OR_INVERTED);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXnand:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_NAND);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
case GXset:
glamor: Convert to using libepoxy. Libepoxy hides all the GL versus GLES2 dispatch handling for us, with higher performance. v2: Squash in the later patch to drop the later of two repeated glamor_get_dispatch()es instead (caught by keithp) Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 21:18:20 +01:00
glLogicOp(GL_SET);
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
break;
default:
glamor_fallback("unsupported alu %x\n", alu);
return FALSE;
}
glamor: Add a screen argument to drop an ifdef from glamor_set_alu(). Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2013-12-27 10:17:10 +01:00
glamor: Apply x-indent.sh. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-12-18 20:59:07 +01:00
return TRUE;
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
}