PDA

View Full Version : KTX and EGL



elFarto
08-06-2010, 06:01 AM
Hi

Firstly, the slides from SIGGRAPH are now up (http://www.khronos.org/library/detail/2010-siggraph-opengl-bof/).

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 (http://www.khronos.org/opengles/sdk/tools/KTX/).

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

remdul
08-06-2010, 07:57 AM
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.

Groovounet
08-06-2010, 08:14 AM
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.

elFarto
08-06-2010, 08:51 AM
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.
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

Groovounet
08-06-2010, 10:35 AM
Hummm... no so exciting then.

remdul
08-06-2010, 10:46 AM
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:
* 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

Then relevant 3rd party software will likely pick the format up quickly. Thankfully many image manipulation packages have support for PS plugins.

Alfonse Reinheart
08-06-2010, 01:02 PM
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.

remdul
08-06-2010, 01:38 PM
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).

elFarto
08-07-2010, 02:36 PM
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

Eosie
08-07-2010, 03:41 PM
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.

remdul
08-08-2010, 04:45 PM
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.

Alfonse Reinheart
08-08-2010, 06:08 PM
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.

remdul
08-09-2010, 05:16 AM
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.