Hi Brad, When I first tested the NVTT based compression on my Linux system I found that the NVTT compression was slower than GL based. I then checked the build options of NVTT and the Release build was set, fixing this and then a rebuilding NVTT improved the results so they matched the GL compile time.
As for the idea of having the -texture-process command line option to select which to use, I think this is a good idea. #if'defing the code paths for when NVTT isn't available is a perfectly acceptable thing to do in this instance as we aren't talking about lots of place in the code. Cheers, Robert. On Tue, Oct 26, 2010 at 12:00 PM, Christiansen, Brad <[email protected]> wrote: > Hi, > > I have just finished some basic benchmarking of the three different > compression methods I am playing with with some very surprising results (to > me anyway : ) I created a small test app that used either the current GL > context, NVTT with CUDA or vanilla CPU based NVTT to compress an image to a > specified format. The image was compressed ten times and the total time taken > is given in seconds. I ran the tests on two machines (one laptop and one > desktop). > > Desktop Win7 3.2ghz CPU Geforce GTX275 > -------------------------------------- > CPU CUDA GL > DXT1 17.0 1.47 0.66 > DXT1a 14.22 0.47 > DXT3 12.58 1.48 0.52 > > > Laptop Win7 3.17ghz CPU ATI Mobility FireGL V5700 > ------------------------------------------------- > CPU GL > DXT1 18.61 3.913 > DXT1a 20.65 3.948 > DXT3 18.13 0.977 > > > The main surprise for me was how much faster using the current GL approach is > compared to using NVTT. There is a big difference between the two video cards > but both are much faster than the CPU. I was a bit disappointed at the CUDA > results especially given this will only work on Nvidia cards and some formats > (the DXT1a cuda score isn't given as this output format doesn't support cuda > acceleration atm). > > > Before these tests I was leaning towards defaulting to using NVTT for maximum > compatibility but this doesn't look so good now. > > Cheers, > Brad > > > > > > > DISCLAIMER:--------------------------------------------------------------------------- > This e-mail transmission and any documents, files and previous e-mail messages > attached to it are private and confidential. They may contain proprietary or > copyright > material or information that is subject to legal professional privilege. They > are for > the use of the intended recipient only. Any unauthorised viewing, use, > disclosure, > copying, alteration, storage or distribution of, or reliance on, this message > is > strictly prohibited. No part may be reproduced, adapted or transmitted > without the > written permission of the owner. If you have received this transmission in > error, or > are not an authorised recipient, please immediately notify the sender by > return email, > delete this message and all copies from your e-mail system, and destroy any > printed > copies. Receipt by anyone other than the intended recipient should not be > deemed a > waiver of any privilege or protection. Thales Australia does not warrant or > represent > that this e-mail or any documents, files and previous e-mail messages > attached are > error or virus free. > -------------------------------------------------------------------------------------- > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
