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? I verified this by allowing generic texture
compression formats for GL_TEXTURE_1D in piglit copyteximage test case and reverting the changes due to this patch on mesa. Is this an issue only on swrast?
That's what the bug reported, don't recall testing other drivers.
Returning GL_INVALID_ENUM error for generic texture compression formats in glTexImage1D() and glCopyTexImage1D() doesn't seem to follow the OpenGL specification. Spec does allow GL_INVALID_ENUM error for a similar scenario in case of glCompressedTexImage1D(). Please correct me if I'm missing something.
I guess I'd like to check what either NVIDIA or AMD do in some of these cases.
AFAIK, the various DXT, LATC, etc compressed formats are only spec'd to work with 2D textures, not 1D. Since 1D textures are generally pretty small to start with, there's not a lot of value in compressed 1D textures. Plus, if a compressed 1D texture uses 4 or 8 bytes to store a 4x1 block of texels, there's only 50% or 0% memory savings with compression.
If you can post your patch for the piglit test I can run it with the NVIDIA driver and see what it does.
-Brian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
