New Texture Tools from NVIDIA

Tips for creating and manipulating planet textures for Celestia.
Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 22 years 9 months
Location: Seattle, Washington, USA

New Texture Tools from NVIDIA

Post #1by chris » 07.03.2007, 21:21

Interesting news for people creating large DXT textures. The new Texture Tools suite from from NVIDIA features a GPU-accelerated compressor that can run an order of magnitude faster than the CPU-based tools:

http://developer.nvidia.com/object/texture_tools.html

And an overview from Beyond3D:

http://www.beyond3d.com/articles/nvtool ... x.php?p=02

I haven't had a chance to try them out myself yet.

--Chris

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 7 months
Location: Hamburg, Germany

Re: New Texture Tools from NVIDIA

Post #2by t00fri » 07.03.2007, 22:36

chris wrote:Interesting news for people creating large DXT textures. The new Texture Tools suite from from NVIDIA features a GPU-accelerated compressor that can run an order of magnitude faster than the CPU-based tools:

http://developer.nvidia.com/object/texture_tools.html

And an overview from Beyond3D:

http://www.beyond3d.com/articles/nvtool ... x.php?p=02

I haven't had a chance to try them out myself yet.

--Chris


That code is apparently based on Simon Brown's squish-1.9.

http://www.sjbrown.co.uk/?code=squish

I am in contact with Simon since a while and about to implement his code also into my forthcoming 'txtools' for compressing DXT5nm and DXT3. Simon's compressor indeed has a smaller RMS error than the "classical" nvDXT code, but the code I have is really slow. So the catch is clearly the GPU support.

Speed was the reason why I have subscribed to the latest DevIL library for now.

I am also in discussion with Simon, how to speed-optimize DXT5nm compression, given the fact that due to the texel normalization condition of normalmaps the DXT compression is effectively a 2D task rather than a 3D one...

Bye Fridger
Image

icastano
Posts: 11
Joined: 03.05.2007
With us: 17 years 6 months

Post #3by icastano » 13.05.2007, 07:11

DXT5nm stores only the X coordinate of the normal in the color block. I wrote a single channel cluster fit implementation and without SIMD optimizations it performed slightly slower than generic SIMD optimized color compressor. Since the input is now scalar, SIMD optimizations are not as easy to implement and not as efficient, so I wouldn't expect a large speedup.

On the other side, it might be a better idea to brute-force it. You would store the X component on the G channel that as 6 bits of precision, so the total number of possible endpoint combinations is 2^6*2^6=2^12=4096. 4096 error evaluations might be faster than ~992 least squares minimizations.

danielj
Posts: 1477
Joined: 15.08.2003
With us: 21 years 3 months

Post #4by danielj » 20.05.2007, 19:53

I downloaded it.Can I use it in the same script of the nmtools or does it require some compiling?


icastano wrote:DXT5nm stores only the X coordinate of the normal in the color block. I wrote a single channel cluster fit implementation and without SIMD optimizations it performed slightly slower than generic SIMD optimized color compressor. Since the input is now scalar, SIMD optimizations are not as easy to implement and not as efficient, so I wouldn't expect a large speedup.

On the other side, it might be a better idea to brute-force it. You would store the X component on the G channel that as 6 bits of precision, so the total number of possible endpoint combinations is 2^6*2^6=2^12=4096. 4096 error evaluations might be faster than ~992 least squares minimizations.

icastano
Posts: 11
Joined: 03.05.2007
With us: 17 years 6 months

Post #5by icastano » 21.05.2007, 00:50

Keep in mind that the library is still in alpha and there may be bugs or errors. In particular, I recently fixed a problem in the normalmap mipmap generation, that is still not fixed in the official binary release from NVIDIA. So, for now consider it an evaluation version and if you find any problems or have any comments feel free to send them to us.

Thanks!

Avatar
dirkpitt
Developer
Posts: 674
Joined: 24.10.2004
With us: 20 years

Post #6by dirkpitt » 21.05.2007, 03:24

The GPU acceleration requires CUDA, which unfortunately "requires 8-Series graphics card and a specific driver for this beta release" (version 0.8).

Why the steep requirements? I'm sure some types of calculations would probably require the new features in a G80, but just doing least squares?

Don. Edwards
Posts: 1510
Joined: 07.09.2002
Age: 59
With us: 22 years 2 months
Location: Albany, Oregon

Post #7by Don. Edwards » 21.05.2007, 04:39

From what I read, the CUDA libraries are also compatible with the 7 series cards as well. I have them installed and have played with them a little. Again we are still limited to doing small textures, albeit at a slightly faster pace.

Don. Edwards
I am officially a retired member.
I might answer a PM or a post if its relevant to something.

Ah, never say never!!
Past texture releases, Hmm let me think about it

Thanks for your understanding.

icastano
Posts: 11
Joined: 03.05.2007
With us: 17 years 6 months

Post #8by icastano » 21.05.2007, 23:20

dirkpitt, CUDA is not just a programming language or a new API, but an entirely different hardware architecture. In order to do high quality DXT compression on the GPU you need thread communication and synchronization and it's possible to do that only with G80 hardware and up. It also uses integer arithmetic extensively, which is only available on most recent hardware.

Hope that addresses your concerns.


Return to “Textures”