2 questions on texture streaming
Members - Reputation: 391
Posted 27 November 2012 - 04:01 AM
Firstly, I've been studying Black Ops 2 recently and it's fairly obvious they use some serious texture streaming. 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. That would mean though that the end user would need a certain amount of free disk space and aren't there xboxes available with no HDD? I can't imagine they stream them from the DVD.
Secondly, when you see the level loading, you can see the MIPs loading in gradually (which is great eye candy in my opinion, I love trying to work out how things work), so to me this must mean they don't store their textures atomically (i.e. one texture file with all the MIP levels in it). So if they are separate, 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? I'm going to do some texts of this at some point but before I possibly waste my time, does anyone know roughly how it works? Am I on track?
Members - Reputation: 4605
Posted 27 November 2012 - 04:32 AM
I think that the lacking HDD support (think of Xbox I) on consoles was one of the major reasons to use streaming. The benefit of streaming is not only the reduced memory impact, but although the asynchroniously nature. Time isn't the most critical issue once you start streaming.
I can't imagine they stream them from the DVD
Why not, when using DDS you can access the single mipmap levels easy enough. And you don't need to read every single mipmap-level, dividing your texture mipmaps into two sections (low/hi) is often enough.
(i.e. one texture file with all the MIP levels in it)
Loading and decompression can be done in an async. thread. Uploading the data to the videocard is most likely done by DMA, therefore the time impact could be quite small.
So if they are separate, isn't it going to be pretty slow to load in an image, lock the texture on the card,
Edited by Ashaman73, 27 November 2012 - 04:37 AM.
My game: Gnoblins
Developer journal about Gnoblins
Small goodies: Simple alpha transparency in deferred shader
Moderators - Reputation: 13554
Posted 27 November 2012 - 05:00 AM
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.
Edited by Hodgman, 27 November 2012 - 05:06 AM.
Moderators - Reputation: 13554
Posted 27 November 2012 - 07:49 AM
Definately. If you're making a PC game, you don't need to put in half the optimisation effort that console devs do! Firstly you'll be loading your data from a HDD (or even SSD) instead of a DVD, and secondly, you don't have some platform gatekeeper that will block the release of your game unless you meet arbitrary quality requirements on loading screens
I'm guessing it's better to just get streaming working in general and then concentrate on the efficiency of loading data.