SLDEV Discussion - Texture Cache Plan of Attack

From Second Life Wiki
Revision as of 15:38, 14 June 2008 by Buckaroo Mu (talk | contribs) (Base article - creating in progress, saving with a "Don't work on me yet" flag.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

DO NOT EDIT - CREATION IN PROGRESS

Discussion is underway in the SLDev Mailing List regarding options to overhaul the texture cache. Mostly the plan involves storing decompressed textures, rather than the JPG2000 compressed versions, which allows the Texture Fetch operations to skip the decode, which is currently the major bottleneck in the cache system. This article is for summarizing, planning, and status of this project. Please discuss via the SLDev mailing list.

Overview

Current Implementation

Currently, the client will download uncached JPG2000 textures from the region/asset servers, progressively decode and apply them to the faces rendered in whatever quality level is currently available. As more data is downloaded, it is further decoded, and the quality rendered goes up. Textures are cached in a three-part system sharing space with the VFS, described in the Texture Cache article.

New Plan

The discussion on the SLDev list has been very helpful in nailing down ways to improve the cache. The biggest change will be caching of textures in an un-compressed format - TGA or Raw - while preserving the existing obfuscation technique to prevent direct ripping of the cached images. In addition, the cache settings will be split into two separate caches - the VFS for objects that use it currently, and a completely new layer of cache exclusively for textures.

Steps

Rework Cache to store multiple formats

Currently, the texture cache can read TGA and JPG2000 files from the cache. However, it has no way to write TGA to the cache. The interface between llTextureFetch and llTextureCache will need to be refactored to support storing and retrieving in a format-agnostic way, allowing JPG2000, TGA, and Raw to to exist simultaneously in the cache, with the possibility of adding others down the line if needed relatively easily.

In short, the calls from llTextureFetch to llTextureCache, and the return data, should include a Format Identifier, a block of data for the image itself (in whatever format is indicated by the Format Identifier), and any other details that may be required such as data size, image dimensions, and color depth. llTexureCache should be able to store this data in a format-agnostic way. Metadata would be stored in the cache index, discussed below.

Rework Cache Index for Greater Storage

Currently, the Texture Cache is part of the VFS, and is limited to 800MB - 80% of the total "cache size", the other 20% of which is reserved for the VFS.