Roland Scheidegger wrote: > 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, I'd say your patches looks good. I just added a new Glean test that exercises all the different combinations of format/type/internalFormat parameters for glTexImage2D (and glDrawPixels). You should test the r200 driver with it to be sure all the conversions are working correctly. -Brian ------------------------------------------------------------------------- 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
