Kristian Høgsberg wrote:
On 9/5/06, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
Shawn Starr wrote:
> The Fedora people have been hanging on to a patch for Mesa since
> 6.4.1 for the r300, I am currently using this patch without issue
> (for all the latest compiz stuff). Is there a reason this isn't in
> 6.5.x yet?
> - return do32bpt ? _dri_texformat_rgba8888 :
> + return do32bpt ? _dri_texformat_argb8888 :
What is the reason this is needed? The chip and driver can handle both
formats, and the driver is free to choose an internal representation.
The exact same code can be found in other drivers (radeon, r200 at
least). I think rgba8888 is chosen instead of argb8888 because of the
lower cost converting a given texture to the internal format (because it
probably already is in rgba8888 format).
The problem is that while the hardware both argb8888 and rgba8888, the
driver always only configures the hardware to use one of these. Which
means that texture upload for argb8888 is just a memcpy, while
rgba8888 upload has to swap. For implementing
GLX_EXT_texture_from_pixmap, it just happens to choose the wrong
format, so texture upload from an X pixmap always has to swap.
Ideally, the driver should configure the hardware to use the right
format so both cases reduce to memcpy, but the patch just swaps the
slow and fast case so that the AIGLX texture_from_pixmap
implementation hits the memcpy path.
I've looked at that and indeed, chances that we actually hit a fast
memcopy path when using rgba8888 is about as big as hell freezing, at
least on little endian. Even after modifying texstore_rgba8888 (see
patch), it'll just never happen. Everyone and their uncle uses just
GL_UNSIGNED_BYTE as type, and since we're using _mesa_texformat_rgba8888
(not the _rev type) that will cause a slow path. Not sure what
applications tend to use on big endian, but if they are doing the same
they won't hit the fast path neither.
So, it looks to me like radeon/r200/r300 should always just use argb8888
instead (patch for r200 attached), not least because there is much more
optimization in mesa's texstore function for this (all normal component
swapping requires a temporary image with texstore_rgba8888, but does not
with texstore_argb8888), and it would not only help for tfp, but some
other apps could benefit too (ut2k3 uses GL_BGRA src format and should
hit the memcopy path too - not that it would really make a performance
difference).
In theory it might be possible to configure the chip to do endianness
swapping on its own (so we could use the rgba8888_rev format in cases
the src format is rgba8888), but it's probably not worth the effort. Not
for r300 though, I think it could easily do better, as the chip supports
free swizzling of texture components it seems.
Roland
Index: texstore.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/main/texstore.c,v
retrieving revision 1.119
diff -u -r1.119 texstore.c
--- texstore.c 10 Aug 2006 04:14:05 -0000 1.119
+++ texstore.c 8 Sep 2006 11:50:40 -0000
@@ -1066,7 +1066,25 @@
dstFormat == &_mesa_texformat_rgba8888 &&
baseInternalFormat == GL_RGBA &&
((srcFormat == GL_RGBA && srcType == GL_UNSIGNED_INT_8_8_8_8) ||
- (srcFormat == GL_ABGR_EXT && srcType == GL_UNSIGNED_INT_8_8_8_8_REV))) {
+ (srcFormat == GL_RGBA && srcType == GL_UNSIGNED_BYTE && !littleEndian)
||
+ (srcFormat == GL_ABGR_EXT && srcType == GL_UNSIGNED_INT_8_8_8_8_REV) ||
+ (srcFormat == GL_ABGR_EXT && srcType == GL_UNSIGNED_BYTE &&
littleEndian))) {
+ /* simple memcpy path */
+ memcpy_texture(ctx, dims,
+ dstFormat, dstAddr, dstXoffset, dstYoffset, dstZoffset,
+ dstRowStride,
+ dstImageOffsets,
+ srcWidth, srcHeight, srcDepth, srcFormat, srcType,
+ srcAddr, srcPacking);
+ }
+ else if (!ctx->_ImageTransferState &&
+ !srcPacking->SwapBytes &&
+ dstFormat == &_mesa_texformat_rgba8888_rev &&
+ baseInternalFormat == GL_RGBA &&
+ ((srcFormat == GL_RGBA && srcType == GL_UNSIGNED_INT_8_8_8_8_REV) ||
+ (srcFormat == GL_RGBA && srcType == GL_UNSIGNED_BYTE && littleEndian) ||
+ (srcFormat == GL_ABGR_EXT && srcType == GL_UNSIGNED_INT_8_8_8_8) ||
+ (srcFormat == GL_ABGR_EXT && srcType == GL_UNSIGNED_BYTE &&
!littleEndian))) {
/* simple memcpy path */
memcpy_texture(ctx, dims,
dstFormat, dstAddr, dstXoffset, dstYoffset, dstZoffset,
Index: r200_tex.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_tex.c,v
retrieving revision 1.20
diff -u -r1.20 r200_tex.c
--- r200_tex.c 7 Oct 2004 23:30:30 -0000 1.20
+++ r200_tex.c 8 Sep 2006 12:02:54 -0000
@@ -332,7 +332,7 @@
case GL_UNSIGNED_SHORT_1_5_5_5_REV:
return _dri_texformat_argb1555;
default:
- return do32bpt ? _dri_texformat_rgba8888 : _dri_texformat_argb4444;
+ return do32bpt ? _dri_texformat_argb8888 : _dri_texformat_argb4444;
}
case 3:
@@ -349,7 +349,7 @@
case GL_UNSIGNED_SHORT_5_6_5_REV:
return _dri_texformat_rgb565;
default:
- return do32bpt ? _dri_texformat_rgba8888 : _dri_texformat_rgb565;
+ return do32bpt ? _dri_texformat_argb8888 : _dri_texformat_rgb565;
}
case GL_RGBA8:
@@ -357,7 +357,7 @@
case GL_RGBA12:
case GL_RGBA16:
return !force16bpt ?
- _dri_texformat_rgba8888 : _dri_texformat_argb4444;
+ _dri_texformat_argb8888 : _dri_texformat_argb4444;
case GL_RGBA4:
case GL_RGBA2:
@@ -370,7 +370,7 @@
case GL_RGB10:
case GL_RGB12:
case GL_RGB16:
- return !force16bpt ? _dri_texformat_rgba8888 : _dri_texformat_rgb565;
+ return !force16bpt ? _dri_texformat_argb8888 : _dri_texformat_rgb565;
case GL_RGB5:
case GL_RGB4:
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
