(Extra terms in summary are to be Google friendly, to greater inform the general populace). This is quite widely known, but as far as I can tell, it's never been actually submitted as a bug report, I figured it deserved that. The unichrome driver in Mesa does not work with Compiz (via AIGLX, I guess it's possible Xgl would work) - I don't actually have one of these cards myself, but I believe it's because support for non-power-of-two textures is lacking. The bottom of http://www.linux-archive.org/fedora-development/7371-driver-transition-via-openchrome.html is probably a good reference. I don't know if anyone's interested in fixing this, or if it's even possible (see Adam Jackson's speculation that the cards themselves may not support it), but I figured it deserved to be immortalized in a bug report. :)
Actually there are two things needed for the unichrome driver to support this stuff 1) Accelerated copypixels. 2) NPOT textures. The unichromes do not natively support NPOT textures, however they allow the level0 mipmap stride to be arbitrarily specified (if 32 bytes aligned). But the texture width and height still needs to be a power of two. So the driver can fake support quite easily if texture coordinates are within 0 <= s <= width and 0 <= t <= height. For primitives with vertex texture coordinates outside of these limits the driver either would need to fall back to software or split the primitive to do wrapping correctly. /Thomas
(In reply to comment #1) > > 1) Accelerated copypixels. That shouldn't be necessary with GLX_MESA_copy_sub_buffer.
Openchrome is no longer supported by Mesa
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.