Hi
Firstly, the slides from SIGGRAPH are now up.
There are 2 items in there I haven’t seen discussed. One is KTX (Khronos Texture file format, think DirectX’s DDS file type for OpenGL). The spec for it is here.
The other item which is mentioned in the Ecosystem pdf, is a version of EGL for the desktop, replacing the dreaded OpenGL32.dll on Windows (and libGL.so on Linux).
Regards
elFarto
Thanks for the links.
KTX looks interesting, but it doesn’t seem to support the DXT formats? I have looked over it only briefly, but saw no mention of it.
And it needs to be integrated in tools or it needs a DDS to KTX converter… Good initiative but in progress. If it is limited to ETC… who cares and it could be very disappointing? A compressor that needs minutes to hours to compress a texture doesn’t rich the tool chain.
EGL on desktop… finally! 
One trouble is that I haven’t managed to run the sample provided with AMD drivers without a crash at start. I’m looking forward for it anyway.
KTX is basically a thin wrapper around the glTexImage*/glCompressTexImage* calls. You directly specify the format to pass to OpenGL in the file, such as COMPRESSED_RGB_S3TC_DXT1_EXT.
Regards
elFarto
Hummm… no so exciting then.
KTX is basically a thin wrapper around the glTexImage*/glCompressTexImage* calls. You directly specify the format to pass to OpenGL in the file, such as COMPRESSED_RGB_S3TC_DXT1_EXT.
Right, I was hoping for that, but are you 100% sure? There are still patent issues surrounding S3TC, which iirc was the reason that texture compression didn’t enter GL core (has it now?; I’m out of the loop!)?
But agreed, if this format is going to get picked up, we’ll need:
Then relevant 3rd party software will likely pick the format up quickly. Thankfully many image manipulation packages have support for PS plugins.
But agreed, if this format is going to get picked up, we’ll need:
- PhotoShop/GIMP input/output plugin
- 3dsmax/maya input plugin
- thumbnail previews in Explorer on Windows
- simple image viewer (cycle mipmaps, cubemap view etc, similar to MS’ DxTex.exe)
- and package this in the official SDK
You missed the most important one: the equivalent of libpng or libjpg: a simply library to load/save the format.
The “Ecosystem” slides mention “libktx”, so that seems already part of the plan.
Anyway, if S3TC is indeed supported by the KTX format, to what degree is it supported by libktx? IMO it would not be complete without DXT (de)compression. Perhaps libsquish could fill in there (like zlib does for libpng).
I’m not sure why you’d want libktx to decompress the texture for you, don’t all video cards released in recent history support S3TC?
Regards
elFarto
You can use a GPU for texture decompression (a simple blit), you cannot use it for compression because it doesn’t compress textures without providing the exact compression algorithm in a shader or a Compute kernel. Basically, it’s not legal to provide or ship the compressing and decompressing algorithm without owning the S3TC patent. Therefore it seems to be legal to use the GPU for decompressing as long as the decompression is done for you in a texture unit or other fixed-function part of the hardware.
Right, but it appears that the patent also covers software decompression as MESA does not implement the S3TC extensions because they were refused a license.
AFAIK decompression in software (without license) is often deemed legal for interoperability reasons, but whether software compression is as well, I doubt that (video codecs anyone?). I’m sure that hardware S3TC compression/decompression is covered solid, however, that is not at issue for libktx.
The main problem I have with libktx (besides the fact that the documentation is atrocious) is that you can’t load images, poke at them, and save them. Loading goes directly to OpenGL. That’s not always bad, but it’s not what I always want to do either.
I think the reason for this is that it originated from GL ES needs. I suspect the intent is to expand it to cover desktop GL.