On 08/17/2012 09:34 AM, Roland Scheidegger wrote: > 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.
I'm surprised we do that. I would have expected uncompressed. > 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). Yeah. The idea is that a GL_COMPRESSED_WHATEVER internal format means "feel free to pick a compressed format, if you want". So we need to allow those internal formats for 1D/3D, but we should probably always pick an uncompressed format. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
