Texture Compression in OpenGL

Started by
8 comments, last by Geri 10 years, 4 months ago

I'm trying to get a firm grasp on the texture compression formats available with OpenGL. Am I getting warm?

S3TC: Equivalent to BC1, BC2 and BC3. As far as I know no version of OpenGL has any guarantees as to whether this is supported, but it is probably available on just about every modern desktop GPU. Safe to assume it is supported?

RGTC: Equivalent to BC4 and BC5. Not sure what the spec says, but I'm guessing that like S3TC it is probably not mandatory but likely supported on any DirectX 10 or 11 hardware. RGTC appears in the OpenGL 4.3 core spec, it may have been added earlier. Safe to assume it is supported?

BPTC: Equivalent to BC6H and BC7. Mandatory since OpenGL 4.2. Being core doesn't necessarily guarantee actual hardware support, but I think it is safe to assume that any DirectX 11 hardware will support it natively.

ETC2, EAC: New texture compression format, no DirectX equivalent. Mandatory since OpenGL 4.3, but as far as I know, no GPU currently has hardware support, which means that current implementations of OpenGL 4.3+ are going to be implementing it inside the driver, negating any benefit from it.

ASTC: New texture compression format, no DirectX equivalent. Not mandatory in any version of OpenGL (as of 4.4) and not supported by modern desktop GPUs yet.

Advertisement

PVRTC is common on iOS devices; I guess that if you're porting from (or porting to) (or want to be compatible with) these you're going to need to prepare for coming across it at some point in time. I don't see any GL extension for supporting it in the registry through, so you'd probably be stuck with doing some software transcoding.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

ETC1/ETC2/EAC is very common in mobile (originally developed at Ericsson research, after all).

ETC1 is guaranteed to be supported by Android 2.2 and above. ETC2 and EAC are guaranteed to be included by all conforming OpenGL ES 3.0 implementations, and is part of the WebGL specification.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

wrt to OpenGL, nothing should be assumed. Any feature support required can be and should be check at runtime before using. As for compressed texture formats, support differs widely, especially in the mobile space so again, check for the supported feature and use if its available, never assume. While DX driver writers have to follow the letter of the law based on the specification, OpenGL is not so lucky. From my personal experience, vendors seem to interpret the specs in different ways. I've have 3 different mobille GPU and give 3 different behavior when compiling simple shaders ( ARM Mali-400, PowerVR SGX ( dont't remember the version, but its the GPU in the TI EVM 335x ) and a Adreno 205 ).

Is there a way to see if there is actual hardware support for a compression format? For example, if you ship a OpenGL 4.3+ game, here is no point in compressing a texture as ETC2 or EAC if the driver is just going to uncompress it before uploading it to graphics memory.

Without actually doing a runtime query there is no way to know whether or not a particular compressed format is supported in general. You could build a known device list for a particular supported feature, in this case compressed texture formats. Compressed textures have several benefits and are usually highly recommended to be used.

1. Compressed textures takes up less space both on secondary storage, and RAM, to include VRAM. So for platforms like mobile devices, where storage space is a premium or network bandwidth is not free, this is a plus.

2. Compressed formats that are supported by the GPU stays compressed and the GPU have specialized HW to access these textures. There is no decompression for upload, the actual compressed data is uploaded. This ties in to #1, uploading compressed data requires less transfer bandwith..another plus.

The problem with a known device list is that it gets out of date very fast.

In general I reckon you can safely assume that the S3TC formats are ubiquitously supported; D3D supports them and in D3D10+ support is mandatory. For any other compression format you can assume nothing, unless you're talking about something that the vendor explicitly supports and recommends, such as PVRTC on iOS.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

It's not hard to build the base table, at least on the mobile side of things:

- Any mobile chip from NVidia supports ST3C.

- Any mobile chip from Qualcom supports ATITC.

- Any mobile chip from PowerVR supports PVRTC.

- All iOS devices support PVRTC.

- All android devices support ETC1.

- All OpenGL ES 3.0-capable devices support EAC and ETC2.

I'm less familiar with desktop, but given that there are only 3 major chipset vendors (AMD, NVidia and Intel), and that Direct3D versions draw hard lines in the sand with respect to feature support, it can't be much worse.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

I'm not really interested in mobile, just desktop.

i think you cant even assume that any kind of texture compression is supported at all. your code must be able to deal with any such situations.

This topic is closed to new replies.

Advertisement