There are some new FP formats in DX10, but I can’t recall if there are any compressed such formats.
The only new formats I’ve seen:
Shared-exponent (HDR) format (RGBE).
Block-compressed 1-2 channel UNORM/SNORM formats.
Don’t know much about them though, except the little blurb in the SDK:
The block compression formats can be used for any of the 2D or 3D texture types ( Texture2D, Texture2DArray, Texture3D, or TextureCube) including mip-map surfaces. The block compression techniques require texture dimensions to be a multiple of 4 (since the implementation compresses on blocks of 4x4 texels). In the texture sampler, compressed formats are always decompressed before texture filtering.
Originally posted by Humus: Nothing wrong with the compression rate. Sometimes the quality isn’t good enough though.
Above in the thread there was something about ‘video textures’. Although I know Imagine (a generic stream processor at Stanford) can run MPEG kernels, a ‘video texture’ format would be a nice thing, instead of GPGPU-ing the issue.
Well, I understand it’s not going to be easy but acceleration is already somewhere in the chip and even consumer electronics get MPEG in a way or the other.
Originally posted by Obli: Well, I understand it’s not going to be easy but acceleration is already somewhere in the chip and even consumer electronics get MPEG in a way or the other.
Oh yeah, even at HD 1920x1080x30fps that won’t be of ANY use for high bandwidth texturing … come on.
Just for kicks, couldn’t a S3TC-like scheme be adopted for floating-point textures, where a 2 component normal map (3rd derived in shader) is compressed using a similar “principal component analysis” (block end-points and linear combination bit-mask)? Haven’t tried this or read anything about it, but it seems plausible, at least in my current state of mind.
Anyway, I believe that’s the deal with the new *NORM formats–2 components for normal maps, 1 component for height-maps and whatnot. It seems that floating-point compression of some kind is clearly afoot here. Probably safe to say that something like this will find its way into OpenGL.
Just for kicks, couldn’t a S3TC-like scheme be adopted for floating-point textures
Oh, I’m sure you could in theory. But what works best for integers doesn’t necessarily work for floats; I imagine the decompression performance characteristics of S3TC won’t carry over to an FP version. And I’m also not sure that the basic assumptions of S3TC work for the average FP texture.
Originally posted by Leghorn: 1. Shared-exponent (HDR) format (RGBE).
Which I guess you could consider compressed, or at least packed. It’s 32 bits instead of 64 for FP16.
Originally posted by Leghorn: 2. Block-compressed 1-2 channel UNORM/SNORM formats.
That’s essentially 3Dc and 3Dc+.
Originally posted by Obli: Well, I understand it’s not going to be easy but acceleration is already somewhere in the chip and even consumer electronics get MPEG in a way or the other.
Well, decoding complete frames is a completely different story. For texturing you need to be able to access any texel at random. Sure, you can decode the entire frame into a texture and then texture from that, but that won’t save you any bandwidth, except maybe AGP/PCIe bus bandwidth and CPU time, which isn’t bad, but a solution to a totally different problem than what texture compression is aimed at.
Originally posted by Obli: There won’t be a glLoadJpeg by sure however.
I can understand in this context my position gets missed. I’m sure no MPEG is going to apply well to hi-perf texturing - mpeg was an example: my concept were that …
Originally posted by Obli: something about ‘video textures’.
… is definetly not considered in actual machinery. Being able to cut something (even at a little performance slowdown) may have sense.
No doubt ZIP is not going to make it to the GPU and provide hi-perf, not even RLE, for the matter, it was a concept, admittedly badly explained by me. If I would have known that compression method XYZ works for GPUs I would have written that one.
That’s essentially 3Dc and 3Dc+.
The 3Dc stuff sounds cool. Do you guys have a spec on that format somewhere (I saw the tech brief)? This gives a pretty good overview: http://www.ati.com/products/radeonx800/3DcWhitePaper.pdf
Looks to be basically a DXT1 format, only with 2 components instead of 3.
I’ve been using DXT5 with x in alpha and y in green, leaving read and blue for gloss and whatnot–not terribly good, but not terribly bad either, at least in terms of a space/quality trade-off.
3Dc is basically the DXT5 alpha compression. There’s a one channel format that’s just one instance of it, and a two channel format that’s just two such blocks. The good thing about this format is that you get two independent channels, whereas in DXT1 you get all channels on a line in color space within a block, which is also why it sucks so bad for normals.