I've seen some systems that stream from DVD to RAM and the HDD at the same time, so that next time it can just stream from the HDD (if one is present). This means that people with cheap (no HDD) Xboxes either have longer loading screens, or lower quality graphics for longer during streaming events.
I was wondering if they will be streaming their textures from the DVD (slow??) or whether they might dump a load of textures (for the current level perhaps) to HDD temporarily (faster) and stream them from there.
Streaming from DVD isn't really that bad (BluRay is worse) as long as you've taken care when creating your game's data archives in order to avoid seeking.
All the console game engines that I've used have put a decent amount of effort into the data tools so that the order of data on disc matches the order in which the game's code will request it (or vice versa).
Microsoft gives some tips here: http://msdn.microsof...5(v=vs.85).aspx
The problem is that when reading from DVD, you want to read data in at least 32KiB blocks, and you want to read as many contiguous blocks as possible. The most optimal layout would have all the bottom-few mips of all the textures in your "level" packed tightly together, then all the next mips next to each other, then all the next-largest mips, etc... (assuming that you're streaming in a "level's worth" of textures at a time).
when using DDS you can access the single mipmap levels easy enough
DDS is also bad because it contains the header, then MIPs in order of highest-resolution to lowest resolution. This means that if you just want to read in the low-res mips first, you are forced to seek over the high-res ones. It might be more optimal to first stream in an entire contiguous array of DDS headers in one operation, and then determine your next move, rather than continually read individual headers off the disc.
I've often seen texture data stored in "texture collection" files rather than as individual textures, to speed up loading operations.
The details for how you'd do this depend on the graphics API. On the consoles, you can manage video memory yourself, so if you know you're not going to create artefacts (because you know that you've set the min-mip-level render-state so that the incoming mips aren't going to be read by the GPU), then you can stream data into the texture's memory allocation without locking.
isn't it going to be pretty slow to load in an image, lock the texture on the card, update it with the incoming higher level MIPs and then unlock it again?
Other APIs have flags to specify that you're not going to overwrite any in-use data with your update/map, so the driver doesn't need to lock. Alternatively, you can create two copies of the texture so that the one being updated isn't the same as the one being used (and then swap the pointers a few frames later), but that of course is paying a RAM penalty to save on locking.