On 8/31/06, Chris Hanson <[EMAIL PROTECTED]> wrote:
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?
I don't know for sure about new hardware, but my guess is that most
drivers compress on the CPU. There is special purpose hardware to do
decompression, but not compression in hardware I've worked with (older
Radeons). Compression in the driver isn't a path that's really
expected to be fast. The trickiest part is to choose the codewords
for each 4x4 block. You need to choose 2 colors to encode and the
other 2 colors are implied by linear interpolation between the 2
stored colors. The quality of compressed images depends on how you
choose these codewords. There are some open-source libraries out
there that handle compression:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
http://www.sjbrown.co.uk/?code=squish
This may not apply to pure software implementations, but there are
patent issues with hardware driver implementations (which is why
Mesa-based drivers don't include support by default).
--
Leif Delgass
[EMAIL PROTECTED]
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
