PDA

View Full Version : nVidia texture formats table has been updated



Ilian Dinev
04-07-2009, 09:07 AM
http://developer.nvidia.com/object/nv_ogl_texture_formats.html

Dark Photon
04-07-2009, 11:09 AM
Excellent! Thanks for the heads-up!

overlay
04-07-2009, 12:02 PM
Does anybody know if there is a similar table about texture formats supported as FBO attachments (render targets) per chipset family?

Dark Photon
04-08-2009, 03:34 PM
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.

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.

Ilian Dinev
04-09-2009, 05:55 AM
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/

zed
04-10-2009, 12:55 AM
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

Jan
04-10-2009, 04:09 AM
AFAIK LATC is nothing else, than RG textures, which in turn are simply DXT compression for 2 channel textures.

Ilian Dinev
04-10-2009, 06:14 AM
DXT1-5 4x->8x compression (i.e. pretty bad ratio OK, yet the image quality is terrible)
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.

Dark Photon
04-10-2009, 09:53 AM
DXT1-5 4x->8x compression (i.e. pretty bad ratio OK, yet the image quality is terrible)
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.

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 (http://news.developer.nvidia.com/2007/10/real-time-ycocg.html)
* FastDXT (RGB and YCoCg DXT compression on CPU and GPU) (http://www.evl.uic.edu/cavern/fastdxt/)