Difference between revisions of "Talk:Texture Cache"
Iron Perth (talk | contribs) |
Iron Perth (talk | contribs) |
||
| Line 24: | Line 24: | ||
Contribution from Tofu Linden from the email discussion | Contribution from Tofu Linden from the email discussion | ||
RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels. | RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels. | ||
[[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT) | [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT) | ||
== Current Cache Hit Rate Issues == | |||
Both Tofu and Steve have made the point they feel cache hit rate issues are a priority.. | |||
Contribution from Steve Linden from email discussion: | |||
2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows: | |||
a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage) | |||
b. Once a frame, reduce the current pixel coverage of all textures by 10%. | |||
This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code "assume that all textures are no longer visible" and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated. | |||
3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed. | |||
4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client > Rendering > Run Multiple Threads, the decoding will be done on the second CPU and go much faster. | |||
He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here: | |||
https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html | |||
[[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT) | |||
Revision as of 01:44, 24 March 2007
We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some "improvments" in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : License Information on GIF and Other LZW-based Technologies -- kerunix Flan
- The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. Seg Baphomet 22:45, 23 March 2007 (PDT)
Databases
There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. Dzonatas Sol 18:23, 23 March 2007 (PDT)
Stats
It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie.—The preceding unsigned comment was added by Iron Perth
TGA
I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.
Additionaly, the "developper area" of the TGA file format could be used to store some usefull information.—The preceding unsigned comment was added by kerunix Flan
- Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. Strife Onizuka 02:22, 24 March 2007 (PDT)
Faster Formats
Contribution from Tofu Linden from the email discussion
RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.
Iron Perth 02:30, 24 March 2007 (PDT)
Current Cache Hit Rate Issues
Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..
Contribution from Steve Linden from email discussion:
2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:
a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)
b. Once a frame, reduce the current pixel coverage of all textures by 10%.
This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code "assume that all textures are no longer visible" and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.
3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.
4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client > Rendering > Run Multiple Threads, the decoding will be done on the second CPU and go much faster.
He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:
https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html
Iron Perth 02:44, 24 March 2007 (PDT)