Roland Scheidegger wrote: > Brian Paul wrote: > >>>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. > > Unfortunately, there seems to be some fundamental problem, as (after > removing the abort()) it fails almost every single test... (roughly two > third of all, including very common and uncommon cases).
I wonder if the rasterization of the textured quad isn't hitting the expected pixels. Perhaps you could use 'xmag' to get a look at the rendering and see if it's the expected 16x16 pattern with the upper-right 8x8 being black. Or maybe a ReadPixels problem? > Oh, and I get very few GL errors too, where type is GL_HALF, like: > testing 301: > Format: GL_RGBA > Type: GL_HALF > IntFormat: glDrawPixels > GL Error: invalid enumerant (0x500) in glDrawPixels > Format: GL_RGBA > Type: GL_HALF > Internal Format: glDrawPixels > testing 302: > Format: GL_RGBA > Type: GL_HALF > IntFormat: 4 > GL Error: invalid operation (0x502) in glTexImage2D > Format: GL_RGBA > Type: GL_HALF > Internal Format: 4 I just fixed that. I was accidentally testing for format==GL_HALF instead of type==GL_HALF. -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
