Am 16.08.2012 23:29, schrieb Anuj Phogat: > On Thu, Aug 16, 2012 at 10:23 AM, Brian Paul <bri...@vmware.com> wrote: >> On 08/15/2012 02:31 PM, Anuj Phogat wrote: >>> >>> On Tue, May 1, 2012 at 2:07 PM, Brian Paul <bri...@vmware.com >>> <mailto:bri...@vmware.com>> wrote: >>> >>> When glTexImage or glCopyTexImage is called with internalFormat >>> being a >>> generic compressed format (like GL_COMPRESSED_RGB) we need to do >>> the same >>> error checks as for specific compressed formats. In particular, >>> check if >>> the texture target is compatible with the format. None of the texture >>> compression formats we support so far work with GL_TEXTURE_1D, for >>> example. >>> >>> See also https://bugs.freedesktop.org/show_bug.cgi?id=49124 >>> >>> >>> Brian, generic texture compression formats with GL_TEXTURE_1D seem to >>> work fine >>> on i965 drivers. >> >> >> Does that wind up using one of the DXT formats? > It uses RGTC for GL_COMPRESSED_RED & GL_COMPRESSED_RG > FXT for GL_COMPRESSED_RGB & GL_COMPRESSED_RGBA Those are also 4x4 based. That said, I think you are right. An implementation must not fail teximage[123]d calls with generic compressed formats. If there's no suitable format available, it is however free to use some suitable uncompressed format (for the specific case, using rgtc here really doesn't make much sense as that's going to be twice as big as uncompressed, unless the hw needs some block-alignment anyway, but I could see why you'd chose that with the code being the same for 1d and 2d textures - it's not like you'd want to optimize that case).
Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
