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

1434 lines
39 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,
int *x, int *y)
{
#ifdef COMPOSITE
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +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
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +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_set_destination_pixmap_priv_nc: set drawable's width x height. Previous implementation set the whole fbo's width and height as the viewpoint. This may increase the numerical error as we may only has a partial region as the valid pixmap. So add a new marco pixmap_priv_get_dest_scale to get proper scale factor for the destination pixmap. For the source/mask pixmap, we still need to consider the whole fbo's size. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 09:25:41 +02:00
glamor_set_destination_pixmap_fbo(glamor_pixmap_fbo * fbo, int x0, int y0, 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
{
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_gl_dispatch *dispatch = glamor_get_dispatch(fbo->glamor_priv);
dispatch->glBindFramebuffer(GL_FRAMEBUFFER, fbo->fb);
glamor-es: Use glVertexAttribPointer to replace glVertexPointer. As GLES2 doesn't support glVertexPointer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-08-03 10:52:19 +02:00
#ifndef GLAMOR_GLES2
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glMatrixMode(GL_PROJECTION);
dispatch->glLoadIdentity();
dispatch->glMatrixMode(GL_MODELVIEW);
dispatch->glLoadIdentity();
glamor-es: Use glVertexAttribPointer to replace glVertexPointer. As GLES2 doesn't support glVertexPointer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-08-03 10:52:19 +02:00
#endif
glamor_set_destination_pixmap_priv_nc: set drawable's width x height. Previous implementation set the whole fbo's width and height as the viewpoint. This may increase the numerical error as we may only has a partial region as the valid pixmap. So add a new marco pixmap_priv_get_dest_scale to get proper scale factor for the destination pixmap. For the source/mask pixmap, we still need to consider the whole fbo's size. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 09:25:41 +02:00
dispatch->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_put_dispatch(fbo->glamor_priv);
}
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_set_destination_pixmap_priv_nc(glamor_pixmap_private * pixmap_priv)
{
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
int w,h;
PIXMAP_PRIV_GET_ACTUAL_SIZE(pixmap_priv, w, h);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
glamor_set_destination_pixmap_fbo(pixmap_priv->base.fbo, 0, 0,
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
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
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_set_destination_pixmap_priv(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
{
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +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
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_set_destination_pixmap_priv_nc(pixmap_priv);
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)
{
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
int err;
glamor_pixmap_private *pixmap_priv =
glamor_get_pixmap_private(pixmap);
glamor : Add dynamic texture uploading feature. Major refactoring. 1. Rewrite the pixmap texture uploading and downloading functions. Add some new functions for both the prepare/finish access and the new performance feature dynamic texture uploading, which could download and upload the current image to/from a private texture/fbo. In the uploading or downloading phase, we need to handle two things: The first is the yInverted option, If it set, then we don't need to flip y. If not set, if it is from a dynamic texture uploading then we don't need to flip either if the current drawing process will flip it latter. If it is from finish_access, then we must flip the y axis. The second thing is the alpha channel hanlding, if the pixmap's format is something like x8a8r8g8, x1r5g5b5 which means it doesn't has alpha channel, but it do has those extra bits. Then we need to wire those bits to 1. 2. Add almost all the required picture format support. This is not as trivial as it looks like. The previous implementation only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format, we have to fallback to cpu. The reason why we can't simply add those other color format is because the exists of picture. one drawable pixmap may has one or even more container pictures. The drawable pixmap's depth can't map to a specified color format, for example depth 16 can mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get get the color format just from the depth value. But the pixmap do not has a pict_format element. We have to make a new one in the pixmap private data structure. Reroute the CreatePicture to glamor_create_picture and then store the picture's format to the pixmap's private structure. This is not an ideal solution, as there may be more than one pictures refer to the same pixmap. Then we will have trouble. There is an example in glamor_composite_with_shader. The source and mask often share the same pixmap, but use different picture format. Our current solution is to combine those two different picture formats to one which will not lose any data. Then change the source's format to this new format and then upload the pixmap to texture once. It works. If we fail to find a matched new format then we fallback. There still is a potential problem, if two pictures refer to the same pixmap, and one of them destroy the picture, but the other still remained to be used latter. We don't handle that situation currently. To be fixed. 3. Dynamic texture uploading. This is a performance feature. Although we don't like the client to hold a pixmap data to shared memory and we can't accelerate it. And even worse, we may need to fallback all the required pixmaps to cpu memory and then process them on CPU. This feature is to mitigate this penalty. When the target pixmap has a valid gl fbo attached to it. But the other pixmaps are not. Then it will be more efficient to upload the other pixmaps to GPU and then do the blitting or rendering on GPU than fallback all the pixmaps to CPU. To enable this feature, I experienced a significant performance improvement in the Game "Mines" :). 4. Debug facility. Modify the debug output mechanism. Now add a new macro: glamor_debug_output(_level_, _format_,...) to conditional output some messages according to the environment variable GLAMOR_DEBUG. We have the following levels currently. exports GLAMOR_DEBUG to 3 will enable all the above messages. 5. Changes in pixmap private data structure. Add some for the full color format supports and relate it to the pictures which already described. Also Add the following new elements: gl_fbo - to indicates whether this pixmap is on gpu only. gl_tex - to indicates whether the tex is valid and is containing the pixmap's image originally. As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may also has a valid fbo or tex attached to it. So we will have to use the above new element to check it true type. After this commit, we can pass the rendercheck testing for all the picture formats. And is much much fater than fallback to cpu when doing rendercheck testing. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
err = glamor_set_destination_pixmap_priv(pixmap_priv);
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_set_planemask(PixmapPtr pixmap, unsigned long planemask)
{
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
if (glamor_pm_is_solid(&pixmap->drawable, planemask)) {
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
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +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: Don't direct call to any gl functions. Create a new structure glamor_gl_dispatch to hold all the gl function's pointer and initialize them at run time , rather than use them directly. To do this is to avoid symbol conflicts. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-09-08 08:05:46 +02:00
glamor_set_alu(struct glamor_gl_dispatch *dispatch, 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-es: Use glVertexAttribPointer to replace glVertexPointer. As GLES2 doesn't support glVertexPointer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-08-03 10:52:19 +02:00
#ifndef GLAMOR_GLES2
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
if (alu == GXcopy) {
dispatch->glDisable(GL_COLOR_LOGIC_OP);
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
return TRUE;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
}
dispatch->glEnable(GL_COLOR_LOGIC_OP);
switch (alu) {
case GXclear:
dispatch->glLogicOp(GL_CLEAR);
break;
case GXand:
dispatch->glLogicOp(GL_AND);
break;
case GXandReverse:
dispatch->glLogicOp(GL_AND_REVERSE);
break;
case GXandInverted:
dispatch->glLogicOp(GL_AND_INVERTED);
break;
case GXnoop:
dispatch->glLogicOp(GL_NOOP);
break;
case GXxor:
dispatch->glLogicOp(GL_XOR);
break;
case GXor:
dispatch->glLogicOp(GL_OR);
break;
case GXnor:
dispatch->glLogicOp(GL_NOR);
break;
case GXequiv:
dispatch->glLogicOp(GL_EQUIV);
break;
case GXinvert:
dispatch->glLogicOp(GL_INVERT);
break;
case GXorReverse:
dispatch->glLogicOp(GL_OR_REVERSE);
break;
case GXcopyInverted:
dispatch->glLogicOp(GL_COPY_INVERTED);
break;
case GXorInverted:
dispatch->glLogicOp(GL_OR_INVERTED);
break;
case GXnand:
dispatch->glLogicOp(GL_NAND);
break;
case GXset:
dispatch->glLogicOp(GL_SET);
break;
default:
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
glamor_fallback("unsupported alu %x\n", alu);
return FALSE;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
}
glamor-es: Use glVertexAttribPointer to replace glVertexPointer. As GLES2 doesn't support glVertexPointer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-08-03 10:52:19 +02:00
#else
glamor_set_alu: Added GXclear support at glamor_solid. We don't need to issue the glamor_fallback at the glamor_set_alu routine, as the caller may support GXclear or other most frequent Ops. Leave it to the caller to determine fallback or not. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-06 15:17:46 +02:00
if (alu != GXcopy)
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
return FALSE;
glamor-es: Use glVertexAttribPointer to replace glVertexPointer. As GLES2 doesn't support glVertexPointer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-08-03 10:52:19 +02:00
#endif
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
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
}
Added strict warning flags to CFLAGS. We miss the strict warning flags for a long time, now add it back. This commit also fixed most of the warnings after enable the strict flags. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 04:42:41 +02:00
static void *
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
_glamor_color_convert_a1_a8(void *src_bits, void *dst_bits, int w, int h, int stride, int revert)
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
{
PictFormatShort dst_format, src_format;
pixman_image_t *dst_image;
pixman_image_t *src_image;
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
int src_stride;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (revert == REVERT_UPLOADING_A1) {
src_format = PICT_a1;
dst_format = PICT_a8;
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
src_stride = PixmapBytePad(w, 1);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
} else {
dst_format = PICT_a1;
src_format = PICT_a8;
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
src_stride = (((w * 8 + 7) / 8) + 3) & ~3;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
}
dst_image = pixman_image_create_bits(dst_format,
w, h,
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
dst_bits,
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
stride);
if (dst_image == NULL) {
return NULL;
}
src_image = pixman_image_create_bits(src_format,
w, h,
src_bits,
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
src_stride);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (src_image == NULL) {
pixman_image_unref(dst_image);
return NULL;
}
pixman_image_composite(PictOpSrc, src_image, NULL, dst_image,
0, 0, 0, 0, 0, 0,
w,h);
pixman_image_unref(src_image);
pixman_image_unref(dst_image);
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
return dst_bits;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
}
#define ADJUST_BITS(d, src_bits, dst_bits) (((dst_bits) == (src_bits)) ? (d) : \
(((dst_bits) > (src_bits)) ? \
(((d) << ((dst_bits) - (src_bits))) \
+ (( 1 << ((dst_bits) - (src_bits))) >> 1)) \
: ((d) >> ((src_bits) - (dst_bits)))))
#define GLAMOR_DO_CONVERT(src, dst, no_alpha, swap, \
a_shift_src, a_bits_src, \
b_shift_src, b_bits_src, \
g_shift_src, g_bits_src, \
r_shift_src, r_bits_src, \
a_shift, a_bits, \
b_shift, b_bits, \
g_shift, g_bits, \
r_shift, r_bits) \
glamor: Touch up some code so indent doesn't get confused. 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:56:15 +01:00
do { \
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
typeof(src) a,b,g,r; \
typeof(src) a_mask_src, b_mask_src, g_mask_src, r_mask_src;\
a_mask_src = (((1 << (a_bits_src)) - 1) << a_shift_src);\
b_mask_src = (((1 << (b_bits_src)) - 1) << b_shift_src);\
g_mask_src = (((1 << (g_bits_src)) - 1) << g_shift_src);\
r_mask_src = (((1 << (r_bits_src)) - 1) << r_shift_src);\
if (no_alpha) \
a = (a_mask_src) >> (a_shift_src); \
else \
a = ((src) & (a_mask_src)) >> (a_shift_src); \
b = ((src) & (b_mask_src)) >> (b_shift_src); \
g = ((src) & (g_mask_src)) >> (g_shift_src); \
r = ((src) & (r_mask_src)) >> (r_shift_src); \
a = ADJUST_BITS(a, a_bits_src, a_bits); \
b = ADJUST_BITS(b, b_bits_src, b_bits); \
g = ADJUST_BITS(g, g_bits_src, g_bits); \
r = ADJUST_BITS(r, r_bits_src, r_bits); \
if (swap == 0) \
(*dst) = ((a) << (a_shift)) | ((b) << (b_shift)) | ((g) << (g_shift)) | ((r) << (r_shift)); \
else \
(*dst) = ((a) << (a_shift)) | ((r) << (b_shift)) | ((g) << (g_shift)) | ((b) << (r_shift)); \
glamor: Touch up some code so indent doesn't get confused. 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:56:15 +01:00
} while (0)
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
Added strict warning flags to CFLAGS. We miss the strict warning flags for a long time, now add it back. This commit also fixed most of the warnings after enable the strict flags. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 04:42:41 +02:00
static void *
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
_glamor_color_revert_x2b10g10r10(void *src_bits, void *dst_bits, int w, int h, int stride, int no_alpha, int revert, int swap_rb)
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
{
int x,y;
unsigned int *words, *saved_words, *source_words;
int swap = !(swap_rb == SWAP_NONE_DOWNLOADING || swap_rb == SWAP_NONE_UPLOADING);
source_words = src_bits;
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
words = dst_bits;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
saved_words = words;
for (y = 0; y < h; y++)
{
DEBUGF("Line %d : ", y);
for (x = 0; x < w; x++)
{
unsigned int pixel = source_words[x];
if (revert == REVERT_DOWNLOADING_2_10_10_10)
GLAMOR_DO_CONVERT(pixel, &words[x], no_alpha, swap,
24, 8, 16, 8, 8, 8, 0, 8,
glamor: Touch up some code so indent doesn't get confused. 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:56:15 +01:00
30, 2, 20, 10, 10, 10, 0, 10);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
else
GLAMOR_DO_CONVERT(pixel, &words[x], no_alpha, swap,
30, 2, 20, 10, 10, 10, 0, 10,
24, 8, 16, 8, 8, 8, 0, 8);
DEBUGF("%x:%x ", pixel, words[x]);
}
DEBUGF("\n");
words += stride / sizeof(*words);
source_words += stride / sizeof(*words);
}
DEBUGF("\n");
return saved_words;
}
Added strict warning flags to CFLAGS. We miss the strict warning flags for a long time, now add it back. This commit also fixed most of the warnings after enable the strict flags. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 04:42:41 +02:00
static void *
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
_glamor_color_revert_x1b5g5r5(void *src_bits, void *dst_bits, int w, int h, int stride, int no_alpha, int revert, int swap_rb)
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
{
int x,y;
unsigned short *words, *saved_words, *source_words;
int swap = !(swap_rb == SWAP_NONE_DOWNLOADING || swap_rb == SWAP_NONE_UPLOADING);
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
words = dst_bits;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
source_words = src_bits;
saved_words = words;
for (y = 0; y < h; y++)
{
DEBUGF("Line %d : ", y);
for (x = 0; x < w; x++)
{
unsigned short pixel = source_words[x];
if (revert == REVERT_DOWNLOADING_1_5_5_5)
GLAMOR_DO_CONVERT(pixel, &words[x], no_alpha, swap,
0, 1, 1, 5, 6, 5, 11, 5,
glamor: Touch up some code so indent doesn't get confused. 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:56:15 +01:00
15, 1, 10, 5, 5, 5, 0, 5);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
else
GLAMOR_DO_CONVERT(pixel, &words[x], no_alpha, swap,
15, 1, 10, 5, 5, 5, 0, 5,
0, 1, 1, 5, 6, 5, 11, 5);
DEBUGF("%04x:%04x ", pixel, words[x]);
}
DEBUGF("\n");
words += stride / sizeof(*words);
source_words += stride / sizeof(*words);
}
DEBUGF("\n");
return saved_words;
}
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
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
/*
* This function is to convert an unsupported color format to/from a
* supported GL format.
* Here are the current scenarios:
*
* @no_alpha:
* If it is set, then we need to wire the alpha value to 1.
* @revert:
REVERT_DOWNLOADING_A1 : convert an Alpha8 buffer to a A1 buffer.
REVERT_UPLOADING_A1 : convert an A1 buffer to an Alpha8 buffer
REVERT_DOWNLOADING_2_10_10_10 : convert r10G10b10X2 to X2B10G10R10
REVERT_UPLOADING_2_10_10_10 : convert X2B10G10R10 to R10G10B10X2
REVERT_DOWNLOADING_1_5_5_5 : convert B5G5R5X1 to X1R5G5B5
REVERT_UPLOADING_1_5_5_5 : convert X1R5G5B5 to B5G5R5X1
@swap_rb: if we have the swap_rb set, then we need to swap the R and B's position.
*
*/
Added strict warning flags to CFLAGS. We miss the strict warning flags for a long time, now add it back. This commit also fixed most of the warnings after enable the strict flags. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 04:42:41 +02:00
static void *
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
glamor_color_convert_to_bits(void *src_bits, void *dst_bits, int w, int h, int stride, int no_alpha, int revert, int swap_rb)
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
{
if (revert == REVERT_DOWNLOADING_A1 || revert == REVERT_UPLOADING_A1) {
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
return _glamor_color_convert_a1_a8(src_bits, dst_bits, w, h, stride, revert);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
} else if (revert == REVERT_DOWNLOADING_2_10_10_10 || revert == REVERT_UPLOADING_2_10_10_10) {
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
return _glamor_color_revert_x2b10g10r10(src_bits, dst_bits, w, h, stride, no_alpha, revert, swap_rb);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
} else if (revert == REVERT_DOWNLOADING_1_5_5_5 || revert == REVERT_UPLOADING_1_5_5_5) {
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
return _glamor_color_revert_x1b5g5r5(src_bits, dst_bits, w, h, stride, no_alpha, revert, swap_rb);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
} else
ErrorF("convert a non-supported mode %x.\n", revert);
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
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
return NULL;
}
glamor : Add dynamic texture uploading feature. Major refactoring. 1. Rewrite the pixmap texture uploading and downloading functions. Add some new functions for both the prepare/finish access and the new performance feature dynamic texture uploading, which could download and upload the current image to/from a private texture/fbo. In the uploading or downloading phase, we need to handle two things: The first is the yInverted option, If it set, then we don't need to flip y. If not set, if it is from a dynamic texture uploading then we don't need to flip either if the current drawing process will flip it latter. If it is from finish_access, then we must flip the y axis. The second thing is the alpha channel hanlding, if the pixmap's format is something like x8a8r8g8, x1r5g5b5 which means it doesn't has alpha channel, but it do has those extra bits. Then we need to wire those bits to 1. 2. Add almost all the required picture format support. This is not as trivial as it looks like. The previous implementation only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format, we have to fallback to cpu. The reason why we can't simply add those other color format is because the exists of picture. one drawable pixmap may has one or even more container pictures. The drawable pixmap's depth can't map to a specified color format, for example depth 16 can mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get get the color format just from the depth value. But the pixmap do not has a pict_format element. We have to make a new one in the pixmap private data structure. Reroute the CreatePicture to glamor_create_picture and then store the picture's format to the pixmap's private structure. This is not an ideal solution, as there may be more than one pictures refer to the same pixmap. Then we will have trouble. There is an example in glamor_composite_with_shader. The source and mask often share the same pixmap, but use different picture format. Our current solution is to combine those two different picture formats to one which will not lose any data. Then change the source's format to this new format and then upload the pixmap to texture once. It works. If we fail to find a matched new format then we fallback. There still is a potential problem, if two pictures refer to the same pixmap, and one of them destroy the picture, but the other still remained to be used latter. We don't handle that situation currently. To be fixed. 3. Dynamic texture uploading. This is a performance feature. Although we don't like the client to hold a pixmap data to shared memory and we can't accelerate it. And even worse, we may need to fallback all the required pixmaps to cpu memory and then process them on CPU. This feature is to mitigate this penalty. When the target pixmap has a valid gl fbo attached to it. But the other pixmaps are not. Then it will be more efficient to upload the other pixmaps to GPU and then do the blitting or rendering on GPU than fallback all the pixmaps to CPU. To enable this feature, I experienced a significant performance improvement in the Game "Mines" :). 4. Debug facility. Modify the debug output mechanism. Now add a new macro: glamor_debug_output(_level_, _format_,...) to conditional output some messages according to the environment variable GLAMOR_DEBUG. We have the following levels currently. exports GLAMOR_DEBUG to 3 will enable all the above messages. 5. Changes in pixmap private data structure. Add some for the full color format supports and relate it to the pictures which already described. Also Add the following new elements: gl_fbo - to indicates whether this pixmap is on gpu only. gl_tex - to indicates whether the tex is valid and is containing the pixmap's image originally. As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may also has a valid fbo or tex attached to it. So we will have to use the above new element to check it true type. After this commit, we can pass the rendercheck testing for all the picture formats. And is much much fater than fallback to cpu when doing rendercheck testing. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
/**
* Upload pixmap to a specified texture.
* This texture may not be the one attached to it.
**/
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
int in_restore = 0;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
static void
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
__glamor_upload_pixmap_to_texture(PixmapPtr pixmap, unsigned int *tex,
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
GLenum format,
GLenum type,
int x, int y, int w, int h,
void *bits, int pbo)
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
{
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_screen_private *glamor_priv =
glamor_get_screen_private(pixmap->drawable.pScreen);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_gl_dispatch *dispatch;
glamor_upload_pixmap: Use glTexImage2D for a fully update. Currently, intel's mesa dri driver will not check pbo for a TexSubImage2D. So we use glTexImage2D if we are a fully updating. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 17:50:09 +02:00
int non_sub = 0;
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
unsigned int iformat = 0;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
dispatch = glamor_get_dispatch(glamor_priv);
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
if (*tex == 0) {
dispatch->glGenTextures(1, tex);
if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP)
gl_iformat_for_depth(pixmap->drawable.depth, &iformat);
else
iformat = format;
glamor_upload_pixmap: Use glTexImage2D for a fully update. Currently, intel's mesa dri driver will not check pbo for a TexSubImage2D. So we use glTexImage2D if we are a fully updating. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 17:50:09 +02:00
non_sub = 1;
assert(x == 0 && y == 0);
}
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
glamor_upload_pixmap: Use glTexImage2D for a fully update. Currently, intel's mesa dri driver will not check pbo for a TexSubImage2D. So we use glTexImage2D if we are a fully updating. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 17:50:09 +02:00
dispatch->glBindTexture(GL_TEXTURE_2D, *tex);
Set filter to GL_NEAREST by default. This is the fastest filter and let's use it by default. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-08 01:50:41 +01:00
dispatch->glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
GL_NEAREST);
dispatch->glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,
GL_NEAREST);
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
dispatch->glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (bits == NULL)
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glBindBuffer(GL_PIXEL_UNPACK_BUFFER,
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
pbo);
glamor_upload_pixmap: Use glTexImage2D for a fully update. Currently, intel's mesa dri driver will not check pbo for a TexSubImage2D. So we use glTexImage2D if we are a fully updating. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 17:50:09 +02:00
if (non_sub)
dispatch->glTexImage2D(GL_TEXTURE_2D,
0, iformat, w, h, 0,
format, type,
bits);
else
dispatch->glTexSubImage2D(GL_TEXTURE_2D,
0, x, y, w, h,
format, type,
bits);
glamor_pixmap: Should bind unpack buffer to 0 after the uploading. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 08:34:43 +01:00
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (bits == NULL)
glamor_pixmap: Should bind unpack buffer to 0 after the uploading. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 08:34:43 +01:00
dispatch->glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_put_dispatch(glamor_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_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
static Bool
_glamor_upload_bits_to_pixmap_texture(PixmapPtr pixmap, GLenum format, GLenum type,
int no_alpha, int revert,
int swap_rb, int x, int y, int w, int h,
int stride, void* bits, int pbo)
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
{
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
glamor_screen_private *glamor_priv = glamor_get_screen_private(pixmap->drawable.pScreen);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_gl_dispatch *dispatch;
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
static float vertices[8];
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
static float texcoords[8] = { 0, 1,
1, 1,
1, 0,
0, 0
};
static float texcoords_inv[8] = { 0, 0,
1, 0,
1, 1,
0, 1
};
float *ptexcoords;
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
float dst_xscale, dst_yscale;
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
GLuint tex = 0;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
int need_flip;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
int need_free_bits = 0;
exports more rendering functions to DDX driver. Exports all necessary rendering functions to DDx drivers, including CopyArea, Glyphs, Composite, Triangles, .... Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-12-09 08:58:19 +01: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
need_flip = !glamor_priv->yInverted;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (bits == NULL)
goto ready_to_upload;
Fixed a1 bug. It seems that mesa has bugs when uploading bitmap to texture. We switch to convert bitmap to a8 format and then upload the a8 texture. Also added a helper routine to dump 1bpp pixmap. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-26 12:28:17 +02:00
if (revert > REVERT_NORMAL) {
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
/* XXX if we are restoring the pixmap, then we may not need to allocate
* new buffer */
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
void *converted_bits;
if (pixmap->drawable.depth == 1)
stride = (((w * 8 + 7) / 8) + 3) & ~3;
converted_bits = malloc(h * stride);
glamor_color_convert: Let the caller to provide destination buffer. As we don't need to allocate new buffer when downloading pixmap to CPU, we change the prototype of the color converting function and let the caller to provide the buffer to hold the result. All the color conversion function supports store the result just at the same place of the source. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 04:00:57 +02:00
if (converted_bits == NULL)
return FALSE;
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
bits = glamor_color_convert_to_bits(bits, converted_bits, w, h,
stride,
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
no_alpha, revert, swap_rb);
if (bits == NULL) {
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
ErrorF("Failed to convert pixmap no_alpha %d,"
"revert mode %d, swap mode %d\n", no_alpha, revert, swap_rb);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
return FALSE;
}
no_alpha = 0;
revert = REVERT_NONE;
swap_rb = SWAP_NONE_UPLOADING;
need_free_bits = TRUE;
}
Add debug message for all the uploading path. The previous message missed the texture restoring path. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-18 10:10:26 +01:00
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
ready_to_upload:
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
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
/* Try fast path firstly, upload the pixmap to the texture attached
* to the fbo directly. */
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
if (no_alpha == 0
&& revert == REVERT_NONE
&& swap_rb == SWAP_NONE_UPLOADING
glamor_largepixmap: Walkaround for large texture's upload. I met a problem with large texture (larger than 7000x7000)'s uploading on SNB platform. The map_gtt get back a mapped VA without error, but write to that virtual address triggers BUS error. This work around is to avoid that direct uploading. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-26 07:09:05 +02:00
&& !need_flip
#ifdef WALKAROUND_LARGE_TEXTURE_MAP
&& pixmap_priv->type != GLAMOR_TEXTURE_LARGE
#endif
) {
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
int fbo_x_off, fbo_y_off;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
assert(pixmap_priv->base.fbo->tex);
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
pixmap_priv_get_fbo_off(pixmap_priv, &fbo_x_off, &fbo_y_off);
assert(x + fbo_x_off >= 0 && y + fbo_y_off >= 0);
assert(x + fbo_x_off + w <= pixmap_priv->base.fbo->width);
assert(y + fbo_y_off + h <= pixmap_priv->base.fbo->height);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
__glamor_upload_pixmap_to_texture(pixmap, &pixmap_priv->base.fbo->tex,
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
format, type,
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
x + fbo_x_off, y + fbo_y_off, w, h,
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
bits, pbo);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
return TRUE;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
}
if (need_flip)
ptexcoords = texcoords;
else
ptexcoords = texcoords_inv;
glamor_set_destination_pixmap_priv_nc: set drawable's width x height. Previous implementation set the whole fbo's width and height as the viewpoint. This may increase the numerical error as we may only has a partial region as the valid pixmap. So add a new marco pixmap_priv_get_dest_scale to get proper scale factor for the destination pixmap. For the source/mask pixmap, we still need to consider the whole fbo's size. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 09:25:41 +02:00
pixmap_priv_get_dest_scale(pixmap_priv, &dst_xscale, &dst_yscale);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
glamor_set_normalize_vcoords(pixmap_priv, dst_xscale,
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
dst_yscale,
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
x, y,
x + w, y + h,
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
glamor_priv->yInverted,
vertices);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
/* Slow path, we need to flip y or wire alpha to 1. */
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
dispatch = glamor_get_dispatch(glamor_priv);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT,
GL_FALSE, 2 * sizeof(float),
vertices);
dispatch->glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
dispatch->glVertexAttribPointer(GLAMOR_VERTEX_SOURCE, 2, GL_FLOAT,
GL_FALSE, 2 * sizeof(float),
ptexcoords);
dispatch->glEnableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
glamor_set_destination_pixmap_priv_nc(pixmap_priv);
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
__glamor_upload_pixmap_to_texture(pixmap, &tex,
format, type,
0, 0, w, h,
bits, pbo);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glActiveTexture(GL_TEXTURE0);
dispatch->glBindTexture(GL_TEXTURE_2D, tex);
dispatch->glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
GL_NEAREST);
dispatch->glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,
GL_NEAREST);
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
#ifndef GLAMOR_GLES2
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glEnable(GL_TEXTURE_2D);
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
#endif
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glUseProgram(glamor_priv->finish_access_prog[no_alpha]);
dispatch->glUniform1i(glamor_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
finish_access_revert[no_alpha],
revert);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glUniform1i(glamor_priv->finish_access_swap_rb[no_alpha],
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
swap_rb);
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
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
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 color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
#ifndef GLAMOR_GLES2
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glDisable(GL_TEXTURE_2D);
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
#endif
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glUseProgram(0);
dispatch->glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
dispatch->glDisableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
dispatch->glDeleteTextures(1, &tex);
dispatch->glBindFramebuffer(GL_FRAMEBUFFER, 0);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_put_dispatch(glamor_priv);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (need_free_bits)
free(bits);
return TRUE;
}
/*
glamor: Fixed one bug when enable dynamic pixmap uploading. When try to upload a pixmap without yInverted set, we must set up a fbo for it to do the y flip. Previous implementation only consider the ax bit. After fix this problem, we can enable the dynamic uploading feature in copyarea function when the yInverted is not set (from Xephyr). Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-06-26 09:51:47 +02:00
* Prepare to upload a pixmap to texture memory.
glamor: Unify the variable name which used to indicate no alpha. The original code use different name and the name is vague. Now change it to no_alpha. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-11 21:27:12 +02:00
* no_alpha equals 1 means the format needs to wire alpha to 1.
glamor: Fixed one bug when enable dynamic pixmap uploading. When try to upload a pixmap without yInverted set, we must set up a fbo for it to do the y flip. Previous implementation only consider the ax bit. After fix this problem, we can enable the dynamic uploading feature in copyarea function when the yInverted is not set (from Xephyr). Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-06-26 09:51:47 +02:00
* Two condtion need to setup a fbo for a pixmap
* 1. !yInverted, we need to do flip if we are not yInverted.
glamor: Unify the variable name which used to indicate no alpha. The original code use different name and the name is vague. Now change it to no_alpha. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-11 21:27:12 +02:00
* 2. no_alpha != 0, we need to wire the alpha.
glamor: Fixed one bug when enable dynamic pixmap uploading. When try to upload a pixmap without yInverted set, we must set up a fbo for it to do the y flip. Previous implementation only consider the ax bit. After fix this problem, we can enable the dynamic uploading feature in copyarea function when the yInverted is not set (from Xephyr). Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-06-26 09:51:47 +02:00
* */
glamor : Add dynamic texture uploading feature. Major refactoring. 1. Rewrite the pixmap texture uploading and downloading functions. Add some new functions for both the prepare/finish access and the new performance feature dynamic texture uploading, which could download and upload the current image to/from a private texture/fbo. In the uploading or downloading phase, we need to handle two things: The first is the yInverted option, If it set, then we don't need to flip y. If not set, if it is from a dynamic texture uploading then we don't need to flip either if the current drawing process will flip it latter. If it is from finish_access, then we must flip the y axis. The second thing is the alpha channel hanlding, if the pixmap's format is something like x8a8r8g8, x1r5g5b5 which means it doesn't has alpha channel, but it do has those extra bits. Then we need to wire those bits to 1. 2. Add almost all the required picture format support. This is not as trivial as it looks like. The previous implementation only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format, we have to fallback to cpu. The reason why we can't simply add those other color format is because the exists of picture. one drawable pixmap may has one or even more container pictures. The drawable pixmap's depth can't map to a specified color format, for example depth 16 can mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get get the color format just from the depth value. But the pixmap do not has a pict_format element. We have to make a new one in the pixmap private data structure. Reroute the CreatePicture to glamor_create_picture and then store the picture's format to the pixmap's private structure. This is not an ideal solution, as there may be more than one pictures refer to the same pixmap. Then we will have trouble. There is an example in glamor_composite_with_shader. The source and mask often share the same pixmap, but use different picture format. Our current solution is to combine those two different picture formats to one which will not lose any data. Then change the source's format to this new format and then upload the pixmap to texture once. It works. If we fail to find a matched new format then we fallback. There still is a potential problem, if two pictures refer to the same pixmap, and one of them destroy the picture, but the other still remained to be used latter. We don't handle that situation currently. To be fixed. 3. Dynamic texture uploading. This is a performance feature. Although we don't like the client to hold a pixmap data to shared memory and we can't accelerate it. And even worse, we may need to fallback all the required pixmaps to cpu memory and then process them on CPU. This feature is to mitigate this penalty. When the target pixmap has a valid gl fbo attached to it. But the other pixmaps are not. Then it will be more efficient to upload the other pixmaps to GPU and then do the blitting or rendering on GPU than fallback all the pixmaps to CPU. To enable this feature, I experienced a significant performance improvement in the Game "Mines" :). 4. Debug facility. Modify the debug output mechanism. Now add a new macro: glamor_debug_output(_level_, _format_,...) to conditional output some messages according to the environment variable GLAMOR_DEBUG. We have the following levels currently. exports GLAMOR_DEBUG to 3 will enable all the above messages. 5. Changes in pixmap private data structure. Add some for the full color format supports and relate it to the pictures which already described. Also Add the following new elements: gl_fbo - to indicates whether this pixmap is on gpu only. gl_tex - to indicates whether the tex is valid and is containing the pixmap's image originally. As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may also has a valid fbo or tex attached to it. So we will have to use the above new element to check it true type. After this commit, we can pass the rendercheck testing for all the picture formats. And is much much fater than fallback to cpu when doing rendercheck testing. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-06-21 12:31:11 +02:00
static int
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_pixmap_upload_prepare(PixmapPtr pixmap, GLenum format, int no_alpha, int revert, int swap_rb)
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
{
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
int flag = 0;
glamor_fbo: Introduce glamor fbo to manage all the fb/tex. This is the first patch to implement a fbo/tex pool mechanism which is like the sna's BO cache list. We firstly need to decopule the fbo/tex from each pixmap. The new glamor_pixmap_fbo data structure is for that purpose. It's somehow independent to each pixmap and can be reused latter by other pixmaps once it's detached from the current pixmap. And this commit also slightly change the way to create a memory pixmap. We will not create a pixmap private data structure by default, instead we will crete that structure when a memory pixmap is attaching a fbo to it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-18 12:21:36 +01:00
glamor_pixmap_private *pixmap_priv;
glamor_screen_private *glamor_priv;
glamor_pixmap_fbo *fbo;
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
GLenum iformat;
glamor_fbo: Introduce glamor fbo to manage all the fb/tex. This is the first patch to implement a fbo/tex pool mechanism which is like the sna's BO cache list. We firstly need to decopule the fbo/tex from each pixmap. The new glamor_pixmap_fbo data structure is for that purpose. It's somehow independent to each pixmap and can be reused latter by other pixmaps once it's detached from the current pixmap. And this commit also slightly change the way to create a memory pixmap. We will not create a pixmap private data structure by default, instead we will crete that structure when a memory pixmap is attaching a fbo to it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-18 12:21:36 +01:00
pixmap_priv = glamor_get_pixmap_private(pixmap);
glamor_priv = glamor_get_screen_private(pixmap->drawable.pScreen);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
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
if (pixmap_priv->base.gl_fbo)
return 0;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
if (pixmap_priv->base.fbo
&& (pixmap_priv->base.fbo->width < pixmap->drawable.width
|| pixmap_priv->base.fbo->height < pixmap->drawable.height)) {
Fixed one potential texture size mismatch problem. There are two cases which we may use a wrong texture size. 1. A pixmap is modified by the client side after it created it. Then the pixmap's width may mismatch the original fbo/tex's size. Thus we need to check this condition when preparing upload the pixmap. 2. We provide two API to download/upload sub region of a textured pixmap. The caller may pass in a larger width then the original pixmap's size, this may happen at putimage and setspans. We need to validate the width and height when do the downloading/uploading. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-25 05:56:43 +02:00
fbo = glamor_pixmap_detach_fbo(pixmap_priv);
glamor_destroy_fbo(fbo);
}
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
if (pixmap_priv->base.fbo && pixmap_priv->base.fbo->fb)
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
return 0;
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
if (!(no_alpha
gles2: Fixed the compilation problem and some bugs. Previous patch doesn't set the offset to zero for GLESv2 path. Now fix it. This patch also fix a minor problem in pixmap uploading preparation. If the revert is not REVERT_NORMAL, then we don't need to prepare a fbo for it. As current mesa i965 gles2 driver doesn't support to set a A8 texture as a fbo target, we must fix this problem. As some A1/A8 picture need to be uploaded, this is the only place a A8 texture may be attached to a fbo. This patch also enable the shader gradient for GLESv2. The reason we disable it before is that some glsl linker doesn't support link different objects which have cross reference. Now we don't have that problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-07-13 03:20:02 +02:00
|| (revert == REVERT_NORMAL)
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
|| (swap_rb != SWAP_NONE_UPLOADING)
|| !glamor_priv->yInverted)) {
/* We don't need a fbo, a simple texture uploading should work. */
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor-pixmap-upload: Create a uploading fbo with a texture only. Just an initial implementation and disabled by default. When uploading a pixmap to a texture, we don't really want to attach the texture to any fbo. So add one fbo type which doesn't has a gl FBO attached to it. This commit can increase the cairo-trace's performance by 10-20%. Now the firefox-planet-gnome is 8.3s. SNA is still the best, only take 3.5s. Thanks for Chris to point out the A1 pixmap uploading bug. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 13:38:29 +01:00
flag = GLAMOR_CREATE_FBO_NO_FBO;
glamor_create_fbo: Concentrate the fbo size/depth checking. Concentrate checking the size/depth when creating fbo. Simply the pixmap creation and the uploading fbo/texture preparing. Also slightly change the uploading fbo's preparation. If don't need fbo, then a fbo only has valid texture should be enough to return. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-21 06:22:14 +01:00
}
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
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
if ((flag == GLAMOR_CREATE_FBO_NO_FBO
&& pixmap_priv->base.fbo && pixmap_priv->base.fbo->tex)
|| (flag == 0
&& pixmap_priv->base.fbo && pixmap_priv->base.fbo->fb))
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
return 0;
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
if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP)
gl_iformat_for_depth(pixmap->drawable.depth, &iformat);
else
iformat = format;
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
if (!glamor_pixmap_ensure_fbo(pixmap, iformat, flag))
return -1;
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
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
return 0;
}
/*
* upload sub region to a large region.
* */
static void
glamor_put_bits(char *dst_bits, int dst_stride, char *src_bits,
int src_stride, int bpp,
int x, int y, int w, int h)
{
int j;
int byte_per_pixel;
byte_per_pixel = bpp / 8;
src_bits += y * src_stride + (x * byte_per_pixel);
for(j = y; j < y + h; j++)
{
memcpy(dst_bits, src_bits, w * byte_per_pixel);
src_bits += src_stride;
dst_bits += dst_stride;
glamor_create_fbo: Concentrate the fbo size/depth checking. Concentrate checking the size/depth when creating fbo. Simply the pixmap creation and the uploading fbo/texture preparing. Also slightly change the uploading fbo's preparation. If don't need fbo, then a fbo only has valid texture should be enough to return. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-21 06:22:14 +01:00
}
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
}
/*
* download sub region from a large region.
*/
static void
glamor_get_bits(char *dst_bits, int dst_stride, char *src_bits,
int src_stride, int bpp,
int x, int y, int w, int h)
{
int j;
int byte_per_pixel;
glamor_fbo: Introduce glamor fbo to manage all the fb/tex. This is the first patch to implement a fbo/tex pool mechanism which is like the sna's BO cache list. We firstly need to decopule the fbo/tex from each pixmap. The new glamor_pixmap_fbo data structure is for that purpose. It's somehow independent to each pixmap and can be reused latter by other pixmaps once it's detached from the current pixmap. And this commit also slightly change the way to create a memory pixmap. We will not create a pixmap private data structure by default, instead we will crete that structure when a memory pixmap is attaching a fbo to it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-18 12:21:36 +01:00
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
byte_per_pixel = bpp / 8;
dst_bits += y * dst_stride + x * byte_per_pixel;
for(j = y; j < y + h; j++)
{
memcpy(dst_bits, src_bits, w * byte_per_pixel);
src_bits += src_stride;
dst_bits += dst_stride;
}
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
}
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
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_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
Bool
glamor_upload_sub_pixmap_to_texture(PixmapPtr pixmap, int x, int y, int w, int h,
int stride, void *bits, int pbo)
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
{
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
GLenum format, type;
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
int no_alpha, revert, swap_rb;
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_pixmap_private *pixmap_priv;
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
Bool force_clip;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
if (glamor_get_tex_format_type_from_pixmap(pixmap,
&format,
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
&type,
&no_alpha,
&revert,
&swap_rb, 1)) {
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_fallback("Unknown pixmap depth %d.\n",
pixmap->drawable.depth);
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
return TRUE;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01: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
if (glamor_pixmap_upload_prepare(pixmap, format, no_alpha, revert, swap_rb))
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
return FALSE;
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
pixmap_priv = glamor_get_pixmap_private(pixmap);
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
force_clip = pixmap_priv->base.glamor_priv->gl_flavor != GLAMOR_GL_DESKTOP
&& !glamor_check_fbo_size(pixmap_priv->base.glamor_priv, w, h);
if (pixmap_priv->type == GLAMOR_TEXTURE_LARGE || force_clip) {
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
RegionRec region;
BoxRec box;
int n_region;
glamor_pixmap_clipped_regions *clipped_regions;
void *sub_bits;
int i,j;
sub_bits = malloc(h * stride);
if (sub_bits == NULL)
return FALSE;
box.x1 = x;
box.y1 = y;
box.x2 = x + w;
box.y2 = y + h;
RegionInitBoxes(&region, &box, 1);
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
if (!force_clip)
clipped_regions = glamor_compute_clipped_regions(pixmap_priv, &region, &n_region, 0, 0, 0);
else
clipped_regions = glamor_compute_clipped_regions_ext(pixmap_priv, &region, &n_region,
pixmap_priv->base.glamor_priv->max_fbo_size,
pixmap_priv->base.glamor_priv->max_fbo_size, 0, 0);
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
DEBUGF("prepare upload %dx%d to a large pixmap %p\n", w, h, pixmap);
for(i = 0; i < n_region; i++)
{
BoxPtr boxes;
int nbox;
int temp_stride;
void *temp_bits;
assert(pbo == 0);
SET_PIXMAP_FBO_CURRENT(pixmap_priv, clipped_regions[i].block_idx);
boxes = RegionRects(clipped_regions[i].region);
nbox = RegionNumRects(clipped_regions[i].region);
DEBUGF("split to %d boxes\n", nbox);
for(j = 0; j < nbox; j++)
{
temp_stride = PixmapBytePad(boxes[j].x2 - boxes[j].x1,
pixmap->drawable.depth);
if (boxes[j].x1 == x && temp_stride == stride) {
temp_bits = (char*)bits + (boxes[j].y1 - y) * stride;
} else {
temp_bits = sub_bits;
glamor_put_bits(temp_bits, temp_stride, bits, stride,
pixmap->drawable.bitsPerPixel,
boxes[j].x1 - x, boxes[j].y1 - y,
boxes[j].x2 - boxes[j].x1,
boxes[j].y2 - boxes[j].y1);
}
DEBUGF("upload x %d y %d w %d h %d temp stride %d \n",
boxes[j].x1 - x, boxes[j].y1 - y,
boxes[j].x2 - boxes[j].x1,
boxes[j].y2 - boxes[j].y1, temp_stride);
if (_glamor_upload_bits_to_pixmap_texture(pixmap, format, type, no_alpha,
revert, swap_rb, boxes[j].x1, boxes[j].y1,
boxes[j].x2 - boxes[j].x1,
boxes[j].y2 - boxes[j].y1,
temp_stride, temp_bits, pbo) == FALSE) {
RegionUninit(&region);
free(sub_bits);
assert(0);
return FALSE;
}
}
RegionDestroy(clipped_regions[i].region);
}
free(sub_bits);
free(clipped_regions);
RegionUninit(&region);
return TRUE;
} else
return _glamor_upload_bits_to_pixmap_texture(pixmap, format, type, no_alpha, revert, swap_rb,
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
x, y, w, h, stride, bits, pbo);
}
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_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
enum glamor_pixmap_status
glamor_upload_pixmap_to_texture(PixmapPtr pixmap)
{
glamor_pixmap_private *pixmap_priv;
void *data;
int pbo;
Fixed a stride problem for textured_drm pixmap. As a textured_drm pixmap has a drm bo attached to it, and it's the DDX layer to set it stride value. In some case, the stride value is not equal to PixmapBytePad(w, depth) which is used within glamor. Then if it is the case, we have two choice, one is to set the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need to download or upload the pixmap. The other option is to change the pixmap's devKind to match the one glamor is using when downloading the pixmap, and restore it to the drm stride after uploading the pixmap. We choose the 2nd option, as GLES doesn't support the first method. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 11:09:06 +02:00
int ret;
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
pixmap_priv = glamor_get_pixmap_private(pixmap);
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
if ((pixmap_priv->base.fbo)
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
&& (pixmap_priv->base.fbo->pbo_valid)) {
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
data = NULL;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pbo = pixmap_priv->base.fbo->pbo;
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
} else {
data = pixmap->devPrivate.ptr;
pbo = 0;
}
if (glamor_upload_sub_pixmap_to_texture(pixmap, 0, 0,
pixmap->drawable.width,
pixmap->drawable.height,
pixmap->devKind,
data, pbo))
Fixed a stride problem for textured_drm pixmap. As a textured_drm pixmap has a drm bo attached to it, and it's the DDX layer to set it stride value. In some case, the stride value is not equal to PixmapBytePad(w, depth) which is used within glamor. Then if it is the case, we have two choice, one is to set the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need to download or upload the pixmap. The other option is to change the pixmap's devKind to match the one glamor is using when downloading the pixmap, and restore it to the drm stride after uploading the pixmap. We choose the 2nd option, as GLES doesn't support the first method. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 11:09:06 +02:00
ret = GLAMOR_UPLOAD_DONE;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
else
Fixed a stride problem for textured_drm pixmap. As a textured_drm pixmap has a drm bo attached to it, and it's the DDX layer to set it stride value. In some case, the stride value is not equal to PixmapBytePad(w, depth) which is used within glamor. Then if it is the case, we have two choice, one is to set the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need to download or upload the pixmap. The other option is to change the pixmap's devKind to match the one glamor is using when downloading the pixmap, and restore it to the drm stride after uploading the pixmap. We choose the 2nd option, as GLES doesn't support the first method. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 11:09:06 +02:00
ret = GLAMOR_UPLOAD_FAILED;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
Fixed a stride problem for textured_drm pixmap. As a textured_drm pixmap has a drm bo attached to it, and it's the DDX layer to set it stride value. In some case, the stride value is not equal to PixmapBytePad(w, depth) which is used within glamor. Then if it is the case, we have two choice, one is to set the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need to download or upload the pixmap. The other option is to change the pixmap's devKind to match the one glamor is using when downloading the pixmap, and restore it to the drm stride after uploading the pixmap. We choose the 2nd option, as GLES doesn't support the first method. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 11:09:06 +02:00
return ret;
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_restore_pixmap_to_texture(PixmapPtr pixmap)
{
glamor_pixmap_upload_texture: Support to upload a sub region of data. Just as the downloading side, we can upload an sub region data to a pixmap's specified region. The data could be in memory or in a pbo buffer. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-10 14:50:14 +02:00
if (glamor_upload_pixmap_to_texture(pixmap) != GLAMOR_UPLOAD_DONE)
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
LogMessage(X_WARNING, "Failed to restore pixmap to texture.\n");
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
}
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
/*
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
* as gles2 only support a very small set of color format and
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
* type when do glReadPixel,
* Before we use glReadPixels to get back a textured pixmap,
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
* Use shader to convert it to a supported format and thus
* get a new temporary pixmap returned.
* */
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_pixmap_fbo *
glamor_es2_pixmap_read_prepare: Just prepare the required region. Don't need to prepare the whole source pixmap. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 09:57:05 +02:00
glamor_es2_pixmap_read_prepare(PixmapPtr source, int x, int y, int w, int h, GLenum format,
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
GLenum type, int no_alpha, int revert, int swap_rb)
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
{
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_pixmap_private *source_priv;
glamor_screen_private *glamor_priv;
ScreenPtr screen;
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_pixmap_fbo *temp_fbo;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_gl_dispatch *dispatch;
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
float temp_xscale, temp_yscale, source_xscale, source_yscale;
static float vertices[8];
static float texcoords[8];
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
screen = source->drawable.pScreen;
glamor_priv = glamor_get_screen_private(screen);
source_priv = glamor_get_pixmap_private(source);
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
temp_fbo = glamor_create_fbo(glamor_priv,
glamor_es2_pixmap_read_prepare: Just prepare the required region. Don't need to prepare the whole source pixmap. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 09:57:05 +02:00
w, h,
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
format,
0);
if (temp_fbo == NULL)
return NULL;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
dispatch = glamor_get_dispatch(glamor_priv);
glamor_set_destination_pixmap_priv_nc: set drawable's width x height. Previous implementation set the whole fbo's width and height as the viewpoint. This may increase the numerical error as we may only has a partial region as the valid pixmap. So add a new marco pixmap_priv_get_dest_scale to get proper scale factor for the destination pixmap. For the source/mask pixmap, we still need to consider the whole fbo's size. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 09:25:41 +02:00
temp_xscale = 1.0 / w;
temp_yscale = 1.0 / h;
Set filter to GL_NEAREST by default. This is the fastest filter and let's use it by default. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-08 01:50:41 +01:00
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_set_normalize_vcoords((struct glamor_pixmap_private*)NULL,temp_xscale,
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
temp_yscale,
0, 0,
glamor_es2_pixmap_read_prepare: Just prepare the required region. Don't need to prepare the whole source pixmap. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 09:57:05 +02:00
w, h,
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_priv->yInverted,
vertices);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glVertexAttribPointer(GLAMOR_VERTEX_POS, 2, GL_FLOAT,
GL_FALSE, 2 * sizeof(float),
vertices);
dispatch->glEnableVertexAttribArray(GLAMOR_VERTEX_POS);
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
pixmap_priv_get_scale(source_priv, &source_xscale, &source_yscale);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
glamor_set_normalize_tcoords(source_priv, source_xscale,
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
source_yscale,
glamor_es2_pixmap_read_prepare: Just prepare the required region. Don't need to prepare the whole source pixmap. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 09:57:05 +02:00
x, y,
x + w, y + h,
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_priv->yInverted,
texcoords);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glVertexAttribPointer(GLAMOR_VERTEX_SOURCE, 2, GL_FLOAT,
GL_FALSE, 2 * sizeof(float),
texcoords);
dispatch->glEnableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
dispatch->glActiveTexture(GL_TEXTURE0);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
dispatch->glBindTexture(GL_TEXTURE_2D, source_priv->base.fbo->tex);
Set filter to GL_NEAREST by default. This is the fastest filter and let's use it by default. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-08 01:50:41 +01:00
dispatch->glTexParameteri(GL_TEXTURE_2D,
GL_TEXTURE_MIN_FILTER,
GL_NEAREST);
dispatch->glTexParameteri(GL_TEXTURE_2D,
GL_TEXTURE_MAG_FILTER,
GL_NEAREST);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_set_destination_pixmap_priv_nc: set drawable's width x height. Previous implementation set the whole fbo's width and height as the viewpoint. This may increase the numerical error as we may only has a partial region as the valid pixmap. So add a new marco pixmap_priv_get_dest_scale to get proper scale factor for the destination pixmap. For the source/mask pixmap, we still need to consider the whole fbo's size. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 09:25:41 +02:00
glamor_set_destination_pixmap_fbo(temp_fbo, 0, 0, w, h);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glUseProgram(glamor_priv->finish_access_prog[no_alpha]);
dispatch->glUniform1i(glamor_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
finish_access_revert[no_alpha],
revert);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glUniform1i(glamor_priv->finish_access_swap_rb[no_alpha],
swap_rb);
dispatch->glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
dispatch->glDisableVertexAttribArray(GLAMOR_VERTEX_POS);
dispatch->glDisableVertexAttribArray(GLAMOR_VERTEX_SOURCE);
dispatch->glUseProgram(0);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_put_dispatch(glamor_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
return temp_fbo;
glamor: Add color conversion support by using new shader. There are two places we need to do color conversion. 1. When upload a image data to a texture. 2. When download a texture to a memory buffer. As the color format may not be supported in GLES2. We may need to do the following two operations to convert dat. a. revert argb to bgra / abgr to rgba. b. swap argb to abgr / bgra to rgba. Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
2011-08-15 18:21:09 +02:00
}
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
/*
* Download a sub region of pixmap to a specified memory region.
* The pixmap must have a valid FBO, otherwise return a NULL.
* */
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
static void *
_glamor_download_sub_pixmap_to_cpu(PixmapPtr pixmap, GLenum format,
GLenum type, int no_alpha,
int revert, int swap_rb,
int x, int y, int w, int h,
int stride, void *bits, int pbo, glamor_access_t access)
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_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
glamor_pixmap_private *pixmap_priv;
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
GLenum gl_access = 0, gl_usage = 0;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
void *data, *read;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_screen_private *glamor_priv =
glamor_get_screen_private(pixmap->drawable.pScreen);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_gl_dispatch *dispatch;
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_pixmap_fbo *temp_fbo = NULL;
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
int need_post_conversion = 0;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
int need_free_data = 0;
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
int fbo_x_off, fbo_y_off;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
data = bits;
pixmap_priv = glamor_get_pixmap_private(pixmap);
Reduce the double check of pixmap's private pointer. As we now add the checking to the Macro, we don't need to check the pointer outside the Macro. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-04 07:40:24 +01:00
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
return NULL;
switch (access) {
case GLAMOR_ACCESS_RO:
gl_access = GL_READ_ONLY;
gl_usage = GL_STREAM_READ;
break;
case GLAMOR_ACCESS_WO:
return bits;
case GLAMOR_ACCESS_RW:
gl_access = GL_READ_WRITE;
gl_usage = GL_DYNAMIC_DRAW;
break;
default:
ErrorF("Glamor: Invalid access code. %d\n", access);
assert(0);
}
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
glamor_set_destination_pixmap_priv_nc(pixmap_priv);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
need_post_conversion = (revert > REVERT_NORMAL);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (need_post_conversion) {
if (pixmap->drawable.depth == 1) {
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
int temp_stride;
temp_stride = (((w * 8 + 7) / 8) + 3) & ~3;
data = malloc(temp_stride * h);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (data == NULL)
return NULL;
need_free_data = 1;
}
}
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
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
pixmap_priv_get_fbo_off(pixmap_priv, &fbo_x_off, &fbo_y_off);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
if (glamor_priv->gl_flavor == GLAMOR_GL_ES2
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
&& !need_post_conversion
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
&& (swap_rb != SWAP_NONE_DOWNLOADING || revert != REVERT_NONE)) {
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (!(temp_fbo = glamor_es2_pixmap_read_prepare(pixmap, x, y, w, h,
format, type, no_alpha,
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
revert, swap_rb))) {
free(data);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
return NULL;
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
x = 0;
y = 0;
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
fbo_x_off = 0;
fbo_y_off = 0;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
dispatch = glamor_get_dispatch(glamor_priv);
Don't need to set GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH. We already adjust the stride of the pixmap, and keep the alignment as 4 should be ok to let the GL/GLES match the stride. Previous version has a unbalanced PACK ROW length seting, and is buggy, now fixed it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-14 16:40:48 +02:00
dispatch->glPixelStorei(GL_PACK_ALIGNMENT, 4);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
if (glamor_priv->has_pack_invert || glamor_priv->yInverted) {
if (!glamor_priv->yInverted) {
assert(glamor_priv->gl_flavor ==
GLAMOR_GL_DESKTOP);
dispatch->glPixelStorei(GL_PACK_INVERT_MESA, 1);
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP && data == NULL) {
assert(pbo > 0);
dispatch->glBindBuffer(GL_PIXEL_PACK_BUFFER, pbo);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glBufferData(GL_PIXEL_PACK_BUFFER,
stride *
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
h,
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
NULL, gl_usage);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
}
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
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
dispatch->glReadPixels(x + fbo_x_off, y + fbo_y_off, w, h, format, type, data);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (!glamor_priv->yInverted) {
assert(glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP);
dispatch->glPixelStorei(GL_PACK_INVERT_MESA, 0);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP && bits == NULL) {
bits = dispatch->glMapBuffer(GL_PIXEL_PACK_BUFFER,
gl_access);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
dispatch->glBindBuffer(GL_PIXEL_PACK_BUFFER, 0);
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
} else {
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
unsigned int temp_pbo;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
int yy;
dispatch = glamor_get_dispatch(glamor_priv);
dispatch->glGenBuffers(1, &temp_pbo);
dispatch->glBindBuffer(GL_PIXEL_PACK_BUFFER,
temp_pbo);
dispatch->glBufferData(GL_PIXEL_PACK_BUFFER,
stride *
Don't need to set GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH. We already adjust the stride of the pixmap, and keep the alignment as 4 should be ok to let the GL/GLES match the stride. Previous version has a unbalanced PACK ROW length seting, and is buggy, now fixed it. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-14 16:40:48 +02:00
h,
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
NULL, GL_STREAM_READ);
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
dispatch->glReadPixels(x + fbo_x_off, y + fbo_y_off, w, h,
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
format, type, 0);
read = dispatch->glMapBuffer(GL_PIXEL_PACK_BUFFER,
GL_READ_ONLY);
for (yy = 0; yy < pixmap->drawable.height; yy++)
Added strict warning flags to CFLAGS. We miss the strict warning flags for a long time, now add it back. This commit also fixed most of the warnings after enable the strict flags. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-05-15 04:42:41 +02:00
memcpy((char*)data + yy * stride,
(char*)read + (h - yy - 1) * stride, stride);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
dispatch->glUnmapBuffer(GL_PIXEL_PACK_BUFFER);
dispatch->glBindBuffer(GL_PIXEL_PACK_BUFFER, 0);
dispatch->glDeleteBuffers(1, &temp_pbo);
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +01:00
}
dispatch->glBindFramebuffer(GL_FRAMEBUFFER, 0);
Fixup glx support Renaming glamor_priv->dispatch and wrapping the access to the dispatch table with a function that also ensured the context was bound. dispatch = glamor_get_dispatch(glamor_priv); ... glamor_put_dispatch(glamor_priv); So that we catch all places where we attempt to call into GL withouta context. As an optimisation we can then do glamor_get_context(); glamor_put_context() around the rendering entry points to reduce the frequency of having to restore the old context. (Along with allowing the context to be recursively acquired and making the old context part of the glamor_egl state.) Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-02-10 13:54:44 +01:00
glamor_put_dispatch(glamor_priv);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +02:00
if (need_post_conversion) {
/* As OpenGL desktop version never enters here.
* Don't need to consider if the pbo is valid.*/
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
bits = glamor_color_convert_to_bits(data, bits,
w, h,
glamor_upload/download: fix 1bpp bug. For A1 to A8's conversion, the stride is different for the source and destination. Previous implementation use the same stride, and may allocate less memory than required. Thus may crash the server when uploading a A1 pixmap. Now fix it. Tested-by: Peng Li <peng.li@intel.com> Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-11 12:57:33 +02:00
stride,
no_alpha,
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
revert, swap_rb);
gles2: Added 1555/2101010 formats support. Added color conversion code to support 1555/2101010 formats,now gles2 can pass the render check with all formats. We use 5551 to represent 1555, and do the revertion if downloading/uploading is needed. For 2101010, as gles2 doesn't support reading the identical formats. We have to use 8888 to represent, thus we may introduce some accurate problem. But anyway, we can pass the error checking in render check, so that may not be a big problem. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-05 16:31:44 +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
if (temp_fbo != NULL)
glamor_destroy_fbo(temp_fbo);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
if (need_free_data)
free(data);
return bits;
}
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
void *
glamor_download_sub_pixmap_to_cpu(PixmapPtr pixmap, int x, int y, int w, int h,
int stride, void *bits, int pbo, glamor_access_t access)
{
GLenum format, type;
int no_alpha, revert, swap_rb;
glamor_pixmap_private *pixmap_priv;
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
Bool force_clip;
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
if (glamor_get_tex_format_type_from_pixmap(pixmap,
&format,
&type,
&no_alpha,
&revert,
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
&swap_rb, 0)) {
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_fallback("Unknown pixmap depth %d.\n",
pixmap->drawable.depth);
return NULL;
}
pixmap_priv = glamor_get_pixmap_private(pixmap);
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
return NULL;
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
force_clip = pixmap_priv->base.glamor_priv->gl_flavor != GLAMOR_GL_DESKTOP
&& !glamor_check_fbo_size(pixmap_priv->base.glamor_priv, w, h);
if (pixmap_priv->type == GLAMOR_TEXTURE_LARGE || force_clip) {
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
RegionRec region;
BoxRec box;
int n_region;
glamor_pixmap_clipped_regions *clipped_regions;
void *sub_bits;
int i,j;
sub_bits = malloc(h * stride);
if (sub_bits == NULL)
return FALSE;
box.x1 = x;
box.y1 = y;
box.x2 = x + w;
box.y2 = y + h;
RegionInitBoxes(&region, &box, 1);
gles2_largepixmap: force clip for a non-large pixmap. One case we need force clip when download/upload a drm_texture pixmap. Actually, this is only meaningful for testing purpose. As we may set the max_fbo_size to a very small value, but the drm texture may exceed this value but the drm texture pixmap is not largepixmap. This is not a problem with OpenGL. But for GLES2, we may need to call glamor_es2_pixmap_read_prepare to create a temporary fbo to do the color conversion. Then we have to force clip the drm pixmap here to avoid large pixmap handling at glamor_es2_pixmap_read_prepare. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-15 07:31:30 +02:00
if (!force_clip)
clipped_regions = glamor_compute_clipped_regions(pixmap_priv, &region, &n_region, 0, 0, 0);
else
clipped_regions = glamor_compute_clipped_regions_ext(pixmap_priv, &region, &n_region,
pixmap_priv->base.glamor_priv->max_fbo_size,
pixmap_priv->base.glamor_priv->max_fbo_size, 0, 0);
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
DEBUGF("start download large pixmap %p %dx%d \n", pixmap, w, h);
for(i = 0; i < n_region; i++)
{
BoxPtr boxes;
int nbox;
int temp_stride;
void *temp_bits;
assert(pbo == 0);
SET_PIXMAP_FBO_CURRENT(pixmap_priv, clipped_regions[i].block_idx);
boxes = RegionRects(clipped_regions[i].region);
nbox = RegionNumRects(clipped_regions[i].region);
for(j = 0; j < nbox; j++)
{
temp_stride = PixmapBytePad(boxes[j].x2 - boxes[j].x1,
pixmap->drawable.depth);
if (boxes[j].x1 == x && temp_stride == stride) {
temp_bits = (char*)bits + (boxes[j].y1 - y) * stride;
} else {
temp_bits = sub_bits;
}
DEBUGF("download x %d y %d w %d h %d temp stride %d \n",
boxes[j].x1, boxes[j].y1,
boxes[j].x2 - boxes[j].x1,
boxes[j].y2 - boxes[j].y1, temp_stride);
/* For large pixmap, we don't support pbo currently.*/
assert(pbo == 0);
if (_glamor_download_sub_pixmap_to_cpu(pixmap, format, type, no_alpha,
revert, swap_rb, boxes[j].x1, boxes[j].y1,
boxes[j].x2 - boxes[j].x1,
boxes[j].y2 - boxes[j].y1,
temp_stride, temp_bits, pbo, access) == FALSE) {
RegionUninit(&region);
free(sub_bits);
assert(0);
return NULL;
}
if (boxes[j].x1 != x || temp_stride != stride)
glamor_get_bits(bits, stride, temp_bits, temp_stride,
pixmap->drawable.bitsPerPixel,
boxes[j].x1 - x , boxes[j].y1 - y,
boxes[j].x2 - boxes[j].x1,
boxes[j].y2 - boxes[j].y1);
}
RegionDestroy(clipped_regions[i].region);
}
free(sub_bits);
free(clipped_regions);
RegionUninit(&region);
return bits;
} else
return _glamor_download_sub_pixmap_to_cpu(pixmap, format, type, no_alpha, revert, swap_rb,
x, y, w, h, stride,
bits, pbo, access);
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
/**
* Move a pixmap to CPU memory.
* The input data is the pixmap's fbo.
* The output data is at pixmap->devPrivate.ptr. We always use pbo
* to read the fbo and then map it to va. If possible, we will use
* it directly as devPrivate.ptr.
* If successfully download a fbo to cpu then return TRUE.
* Otherwise return FALSE.
**/
Bool
glamor_download_pixmap_to_cpu(PixmapPtr pixmap, glamor_access_t access)
{
glamor_pixmap_private *pixmap_priv =
glamor_get_pixmap_private(pixmap);
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
unsigned int stride;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
void *data = NULL, *dst;
glamor_screen_private *glamor_priv =
glamor_get_screen_private(pixmap->drawable.pScreen);
glamor_gl_dispatch *dispatch;
int pbo = 0;
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
return TRUE;
glamor_debug_output(GLAMOR_DEBUG_TEXTURE_DOWNLOAD,
"Downloading pixmap %p %dx%d depth%d\n",
pixmap,
pixmap->drawable.width,
pixmap->drawable.height,
pixmap->drawable.depth);
stride = pixmap->devKind;
if (access == GLAMOR_ACCESS_WO
|| glamor_priv->gl_flavor == GLAMOR_GL_ES2
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_priv->has_pack_invert && !glamor_priv->yInverted)
|| pixmap_priv->type == GLAMOR_TEXTURE_LARGE) {
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
data = malloc(stride * pixmap->drawable.height);
} else {
dispatch = glamor_get_dispatch(glamor_priv);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
if (pixmap_priv->base.fbo->pbo == 0)
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
dispatch->glGenBuffers(1,
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
&pixmap_priv->base.fbo->pbo);
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
glamor_put_dispatch(glamor_priv);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pbo = pixmap_priv->base.fbo->pbo;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
}
Fixed a stride problem for textured_drm pixmap. As a textured_drm pixmap has a drm bo attached to it, and it's the DDX layer to set it stride value. In some case, the stride value is not equal to PixmapBytePad(w, depth) which is used within glamor. Then if it is the case, we have two choice, one is to set the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need to download or upload the pixmap. The other option is to change the pixmap's devKind to match the one glamor is using when downloading the pixmap, and restore it to the drm stride after uploading the pixmap. We choose the 2nd option, as GLES doesn't support the first method. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 11:09:06 +02:00
if (pixmap_priv->type == GLAMOR_TEXTURE_DRM) {
stride = PixmapBytePad(pixmap->drawable.width, pixmap->drawable.depth);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pixmap_priv->base.drm_stride = pixmap->devKind;
Fixed a stride problem for textured_drm pixmap. As a textured_drm pixmap has a drm bo attached to it, and it's the DDX layer to set it stride value. In some case, the stride value is not equal to PixmapBytePad(w, depth) which is used within glamor. Then if it is the case, we have two choice, one is to set the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need to download or upload the pixmap. The other option is to change the pixmap's devKind to match the one glamor is using when downloading the pixmap, and restore it to the drm stride after uploading the pixmap. We choose the 2nd option, as GLES doesn't support the first method. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 11:09:06 +02:00
pixmap->devKind = stride;
}
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
dst = glamor_download_sub_pixmap_to_cpu(pixmap, 0, 0,
pixmap->drawable.width,
pixmap->drawable.height,
pixmap->devKind,
data, pbo, access);
if (!dst) {
if (data)
free(data);
return FALSE;
}
if (pbo != 0)
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pixmap_priv->base.fbo->pbo_valid = 1;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pixmap_priv->base.gl_fbo = GLAMOR_FBO_DOWNLOADED;
glamor_download_sub_pixmap_to_cpu: New function to download subregion. Prepare to optimize the fallback path. We choose the important rendering pathes to optimzie it by using shader. For other pathes, we have to fallback. We may continue to optimize more pathes in the future, but now we have to face those fallbacks. The original fallback is very slow and will download/upload the whole pixmap. From this commit, I will refine it to just download/upload needed part. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 10:39:42 +02:00
pixmap->devPrivate.ptr = dst;
Initial version. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2011-11-02 06:44:50 +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
}
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
/* fixup a fbo to the exact size as the pixmap. */
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
/* XXX LARGE pixmap? */
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
Bool
glamor_fixup_pixmap_priv(ScreenPtr screen, glamor_pixmap_private *pixmap_priv)
{
glamor_pixmap_fbo *old_fbo;
glamor_pixmap_fbo *new_fbo = NULL;
PixmapPtr scratch = NULL;
glamor_pixmap_private *scratch_priv;
DrawablePtr drawable;
GCPtr gc = NULL;
int ret = FALSE;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
drawable = &pixmap_priv->base.pixmap->drawable;
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
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
if (!GLAMOR_PIXMAP_FBO_NOT_EAXCT_SIZE(pixmap_priv))
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
return TRUE;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
old_fbo = pixmap_priv->base.fbo;
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
if (!old_fbo)
return FALSE;
gc = GetScratchGC(drawable->depth, screen);
if (!gc)
goto fail;
scratch = glamor_create_pixmap(screen, drawable->width, drawable->height,
drawable->depth,
GLAMOR_CREATE_PIXMAP_FIXUP);
scratch_priv = glamor_get_pixmap_private(scratch);
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
if (!scratch_priv->base.fbo)
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
goto fail;
ValidateGC(&scratch->drawable, gc);
glamor_copy_area(drawable,
&scratch->drawable,
gc, 0, 0,
drawable->width, drawable->height,
0, 0);
old_fbo = glamor_pixmap_detach_fbo(pixmap_priv);
new_fbo = glamor_pixmap_detach_fbo(scratch_priv);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
glamor_pixmap_attach_fbo(pixmap_priv->base.pixmap, new_fbo);
glamor-fbo-pool: Enable to reuse different size fbo/texture. Fixup three special cases, one is in tile and the other is in composite. Both cases are due to repeat texture issue. Maybe we can refine the shader to recalculate texture coords to support partial texture's repeating. The third is when upload a memory pixmap to texture, as now the texture may not have the exact size as the pixmap, we should not use the full rect coords. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-01-20 02:59:44 +01:00
glamor_pixmap_attach_fbo(scratch, old_fbo);
DEBUGF("old %dx%d type %d\n",
drawable->width, drawable->height, pixmap_priv->type);
DEBUGF("copy tex %d %dx%d to tex %d %dx%d \n",
old_fbo->tex, old_fbo->width, old_fbo->height, new_fbo->tex, new_fbo->width, new_fbo->height);
ret = TRUE;
fail:
if (gc)
FreeScratchGC(gc);
if (scratch)
glamor_destroy_pixmap(scratch);
return ret;
}
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
/*
* We may use this function to reduce a large pixmap to a small sub
* pixmap. Two scenarios currently:
* 1. When fallback a large textured pixmap to CPU but we do need to
* do rendering within a small sub region, then we can just get a
* sub region.
*
* 2. When uploading a large pixmap to texture but we only need to
* use part of the source/mask picture. As glTexImage2D will be more
* efficient to upload a contingent region rather than a sub block
* in a large buffer. We use this function to gather the sub region
* to a contingent sub pixmap.
*
* The sub-pixmap must have the same format as the source pixmap.
*
* */
PixmapPtr
glamor_get_sub_pixmap(PixmapPtr pixmap, int x, int y, int w, int h, glamor_access_t access)
{
glamor_screen_private *glamor_priv;
PixmapPtr sub_pixmap;
glamor_pixmap_private *sub_pixmap_priv, *pixmap_priv;
void *data;
int pbo;
int flag;
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
if (x < 0 || y < 0)
return NULL;
Fixed one potential texture size mismatch problem. There are two cases which we may use a wrong texture size. 1. A pixmap is modified by the client side after it created it. Then the pixmap's width may mismatch the original fbo/tex's size. Thus we need to check this condition when preparing upload the pixmap. 2. We provide two API to download/upload sub region of a textured pixmap. The caller may pass in a larger width then the original pixmap's size, this may happen at putimage and setspans. We need to validate the width and height when do the downloading/uploading. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-25 05:56:43 +02:00
w = (x + w) > pixmap->drawable.width ? (pixmap->drawable.width - x) : w;
h = (y + h) > pixmap->drawable.height ? (pixmap->drawable.height - y) : h;
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
if (access == GLAMOR_ACCESS_WO) {
sub_pixmap = glamor_create_pixmap(pixmap->drawable.pScreen, w, h,
pixmap->drawable.depth, GLAMOR_CREATE_PIXMAP_CPU);
return sub_pixmap;
}
glamor_priv = glamor_get_screen_private(pixmap->drawable.pScreen);
pixmap_priv = glamor_get_pixmap_private(pixmap);
if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv))
return NULL;
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
if (glamor_priv->gl_flavor == GLAMOR_GL_ES2 || pixmap_priv->type == GLAMOR_TEXTURE_LARGE)
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
flag = GLAMOR_CREATE_PIXMAP_CPU;
else
flag = GLAMOR_CREATE_PIXMAP_MAP;
sub_pixmap = glamor_create_pixmap(pixmap->drawable.pScreen, w, h,
pixmap->drawable.depth, flag);
if (sub_pixmap == NULL)
return NULL;
sub_pixmap_priv = glamor_get_pixmap_private(sub_pixmap);
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pbo = sub_pixmap_priv ? (sub_pixmap_priv->base.fbo ? sub_pixmap_priv->base.fbo->pbo : 0): 0;
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
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
if (pixmap_priv->base.is_picture) {
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
sub_pixmap_priv->base.picture = pixmap_priv->base.picture;
sub_pixmap_priv->base.is_picture = pixmap_priv->base.is_picture;
glamor_put_sub_pixmap: Change to use glamor_upload_sub_pixmap. As the pixmap may be attached to a picture, we need to use glamor_upload_sub_pixmap to process it. glamor_copy_n_to_n will not consider the picture case. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:43:44 +02:00
}
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
if (pbo)
data = NULL;
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
else
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
data = sub_pixmap->devPrivate.ptr;
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
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
data = glamor_download_sub_pixmap_to_cpu(pixmap, x, y, w, h, sub_pixmap->devKind,
data, pbo, access);
Shoud return null subpixmap if we fail to get a valid map address. The patch is prepared by Raul Fernandes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86693 Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2013-09-26 23:25:54 +02:00
if(data == NULL) {
fbDestroyPixmap(sub_pixmap);
return NULL;
}
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
if (pbo) {
assert(sub_pixmap->devPrivate.ptr == NULL);
sub_pixmap->devPrivate.ptr = data;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
sub_pixmap_priv->base.fbo->pbo_valid = 1;
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
}
#if 0
struct pixman_box16 box;
PixmapPtr new_sub_pixmap;
int dx, dy;
box.x1 = 0;
box.y1 = 0;
box.x2 = w;
box.y2 = h;
dx = x;
dy = y;
new_sub_pixmap = glamor_create_pixmap(pixmap->drawable.pScreen, w, h,
pixmap->drawable.depth, GLAMOR_CREATE_PIXMAP_CPU);
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_copy_n_to_n(&pixmap->drawable, &new_sub_pixmap->drawable, NULL, &box, 1, dx, dy, 0, 0, 0, NULL);
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
glamor_compare_pixmaps(new_sub_pixmap, sub_pixmap, 0, 0, w, h, 1, 1);
#endif
return sub_pixmap;
}
Fixed all unused variables warnings. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-28 08:55:34 +02:00
void
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
glamor_put_sub_pixmap(PixmapPtr sub_pixmap, PixmapPtr pixmap, int x, int y, int w, int h, glamor_access_t access)
{
glamor_put_sub_pixmap: Change to use glamor_upload_sub_pixmap. As the pixmap may be attached to a picture, we need to use glamor_upload_sub_pixmap to process it. glamor_copy_n_to_n will not consider the picture case. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:43:44 +02:00
void *bits;
int pbo;
glamor_pixmap_private *sub_pixmap_priv;
glamor_render: Don't download whole picture when fallback. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:46:09 +02:00
if (access != GLAMOR_ACCESS_RO) {
sub_pixmap_priv = glamor_get_pixmap_private(sub_pixmap);
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
if (sub_pixmap_priv->base.fbo
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
&& sub_pixmap_priv->base.fbo->pbo_valid) {
glamor_render: Don't download whole picture when fallback. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:46:09 +02:00
bits = NULL;
glamor_largepixmap: first commit for large pixmap. This is the first commit to add support for large pixmap. The large here means a pixmap is larger than the texutre's size limitation thus can't fit into one single texutre. The previous implementation will simply fallback to use a in memory pixmap to contain the large pixmap which is very slow in practice. The basic idea here is to use an array of texture to hold the large pixmap. And when we need to get a specific area of the pixmap, we just need to compute/clip the correct region and find the corresponding fbo. We need to implement some auxiliary routines to clip every rendering operations into small pieces which can fit into one texture. The complex part is the transformation/repeat/repeatReflect and repeat pad and their comination. We will support all of them step by step. This commit just add some necessary data structure to represent the large pixmap, and doesn't change any rendering process. This commit doesn't add real large pixmap support. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-06-10 19:02:30 +02:00
pbo = sub_pixmap_priv->base.fbo->pbo;
glamor_render: Don't download whole picture when fallback. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:46:09 +02:00
} else {
bits = sub_pixmap->devPrivate.ptr;
pbo = 0;
}
Fixed one potential texture size mismatch problem. There are two cases which we may use a wrong texture size. 1. A pixmap is modified by the client side after it created it. Then the pixmap's width may mismatch the original fbo/tex's size. Thus we need to check this condition when preparing upload the pixmap. 2. We provide two API to download/upload sub region of a textured pixmap. The caller may pass in a larger width then the original pixmap's size, this may happen at putimage and setspans. We need to validate the width and height when do the downloading/uploading. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-25 05:56:43 +02:00
assert(x >= 0 && y >= 0);
w = (w > sub_pixmap->drawable.width) ? sub_pixmap->drawable.width : w;
h = (h > sub_pixmap->drawable.height) ? sub_pixmap->drawable.height : h;
glamor_render: Don't download whole picture when fallback. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:46:09 +02:00
glamor_upload_sub_pixmap_to_texture(pixmap, x, y, w, h, sub_pixmap->devKind, bits, pbo);
glamor_put_sub_pixmap: Change to use glamor_upload_sub_pixmap. As the pixmap may be attached to a picture, we need to use glamor_upload_sub_pixmap to process it. glamor_copy_n_to_n will not consider the picture case. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-15 13:43:44 +02:00
}
fallback_optimize: Prepare for downloading/uploading subregion. Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap, can easily used to get and put sub region of a big textured pixmap. And it can use pbo if possible. To support download a big textured pixmap's sub region to another pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP. This type of pixmap has a valid devPrivate.ptr pointer, and that pointer points to a pbo mapped address. Now, we are ready to refine those glamor_prepare_access/glamor_finish_access pairs. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2012-04-09 14:16:07 +02:00
glamor_destroy_pixmap(sub_pixmap);
}
Reference in New Issue Copy Permalink