Excellent! Thanks for the heads-up!
Does anybody know if there is a similar table about texture formats supported as FBO attachments (render targets) per chipset family?
There's an fboCheckSupported tool someone mailed out a while back that works well, though it's not too hard to write one.Originally Posted by overlay
But no I haven't seen what you ask for for multiple chipsets. There's a table for GeForce 6 specifically in GPU Gems 2, Ch 30 (D3D list). And there are bits in the NVidia GPU Programming Guides. But nothing all in one spot I've seen, and nothing cross-vendor.
Maybe it's time to start a table in the wiki? A little tool folks could download and run to generate a report record would fill the bill.
nVidia's SimpleFBO has some helping funcs about enumeration;
Modus has recently published some DXGI results, which should be mostly valid for gl: http://snpow.wordpress.com/
One thing thats buggged me for years,
why havent there been more + better texture compression methods over the years?
DXT1-5 4x->8x compression (i.e. pretty bad ratio OK, yet the image quality is terrible)
I see on that table theres finally something new, COMPRESSED_LUMINANCE_LATC1 etc
but since its only nvidia G80+ and new ATI cards, unless you drastically limit the cards that cam run your stuff, youre stuck with s3tc
AFAIK LATC is nothing else, than RG textures, which in turn are simply DXT compression for 2 channel textures.
GLIM - Immediate Mode Emulation for GL3
16-bit 565 color, with hopes after blending the palette entries it'll reach the original color.
Other compressions require zlib inflate() and optionally idct().
Maybe getting 8888 color entries in a s3tc-like compression could yield better colors. Or returning 256-entry palettes back in business, with options to make up to i.e 1024-entry ones.
Yeah, interpolated RGB565 isn't for everyone.16-bit 565 color, with hopes after blending the palette entries it'll reach the original color.
Other compressions require zlib inflate() and optionally idct().
Maybe getting 8888 color entries in a s3tc-like compression could yield better colors. Or returning 256-entry palettes back in business, with options to make up to i.e 1024-entry ones.
Have you checked out encoding colors in the YCoCg color space using DXT5? Still only 1 byte/texel on average (vs. 0.5 bytes/texel for DXT1), and simple shader math to get RGB back out from the texture sample. You trade alpha for better color quality.
* Real-time YCoCg-DXT Compression
* FastDXT (RGB and YCoCg DXT compression on CPU and GPU)
Posting Permissions
