Eric Sokolowsky wrote:
My tests showed that compressing on the fly every time is slower by a
factor
of 4-6, but once images are compressed they are 2-4 times faster to load.
Thanks for the data bits.
This also requires reading the image back from the video hardware and
writing it back out to disk. (The 4-6x slowdown includes this time.) So if
your constraints are such that you do not re-use your texture images, then
texture compression might not work well for you.
I've been trying to determine who is actually doing the texture compression -- is it
being done by the driver on the CPU side of things, or by the GPU on the card side of
things. If it's being done by the CPU (or could be done by the CPU) it seems like I could
write a portable piece of code to do that work (even on a second thread/CPU) without
needing access to a shared context, and possibly faster. Not that my application needs it,
but it would also be available for writing to disk without a read-back from the card.
I don't know how to ascertain who is doing this work and how it is being done though.
Anyone have any anecdotal evidence either way on this?
--
Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at logrus
"I set the wheels in motion, turn up all the machines, activate the programs,
and run behind the scenes. I set the clouds in motion, turn up light and
sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
