Fixing texture pack stuttering with less ram

[phly95]

Just wondering, what exactly prevents loading texture pack textures like emulating a disc. For example, if the game says "load navi.gcimg" and there is "navi.png" in the texture pack, why can't it load that instead instead of waiting until the texture is actively being used by dolphin? Instead of stuttering, it could behave like a normal gamecube would when reading the disc (and the gamecube never stuttered).

I actually used a trick with the gamecube in hyrule field once to open the lid for a split second (as to not trigger the open disc screen), close it, run the horse farther, right when the disc is recognized, do it again until I ran off a cliff and got stuck falling over and over again. I would prefer a glitch like that for insufficient load speeds than a large intrusive stutter.

This would really reduce the required RAM on some of these beautiful texture packs out there, so I can get by with 6 GBs of RAM. I shouldn't have to prefetch all of the entire game (from hyrule field to the wart on the shop lady's face) when all I'm doing is entering a single room in Twilight Princess.

PS. The specs in my signature are really outdated, I haven't gone around to fixing it yet. Somewhat fixed, but not very specific since I'm on my laptop right now and can't verify anything.

[Shonumi]

(09-29-2015, 02:23 PM)phly95 Wrote: For example, if the game says "load navi.gcimg" and there is "navi.png" in the texture pack, why can't it load that instead instead of waiting until the texture is actively being used by dolphin?

I'm going to take a guess on this and say that it might be really hard to pinpoint where exactly a game says "load navi.gcimg". It would be very helpful to wave your hand and say "Dolphin, whenever you encounter this function, do this instead," but actually determining where that function is within the game's code is the problem. I gather you'd need to analyze the game in a debugger to find out where it's trying to load data to be used as a texture. There might be multiple functions that load this data from the disk for textures as well. I can think of a dozen other logistical issues with trying to pin down a specific "load data from disk for texture" function, but I'll just let real Dolphin devs comment on anything like that.

Something more straightforward would be to load a texture from your HDD/SDD or whatever as soon as texture data hits Dolphin's emulated VRAM and is properly hashed. But you'd still come across (or at least run the risk of) stuttering due to an I/O bottleneck. That would only potentially solve the issue of consuming massive amounts of RAM during gameplay.

Here's a crazy idea that would be an absolute pain to implement, but I think it has some merit. If Dolphin could somehow assign certain textures a priority level, certain textures could be loaded on startup, while others are loaded dynamically as they are encountered in the game. It would probably be something best left to the people making texture packs (they can pick and choose common ones, or do a 50/50 type deal). They could chose smaller textures or lesser used textures to be loaded dynamically.

Like I said, this would be a pain to code properly, especially where to store the priority data. Simplest way I can think of is to just change the extension of any custom texture for any custom texture with priority. E.g. "123456789.png" has priority by default, but "123456789.png.tex" does not. I gather Dolphin doesn't care greatly about the extension (well, the image format itself has to be acceptable) and that the filename/texture hash is what matters, so this method is not entirely intrusive to how things are done now. But it'd be up to individual texture packs to go through and hand-pick what has priority and what doesn't; it'd still be a real mess. I suppose Dolphin itself could automatically assign these priorities based on the relative size of custom textures (bigger textures get priority, smaller ones are loaded dynamically, or maybe vice versa). Or it could just do a lottery type deal (50/50 randomly, half gets priority, half is dynamically loaded).

But that's just me, and that idea's just crazy  

[mimimi]

Isn't decoding the textures the main problem? I mean decode from bmp, png or whatever to the format that is actually used by the GPU? So one step forward could be to do decode all textures at startup, and write them decoded to disk. Then you only need a fast HDD or just a SSD to load, and it should lag less.

[JosJuice]

(09-29-2015, 03:06 PM)Shonumi Wrote: I'm going to take a guess on this and say that it might be really hard to pinpoint where exactly a game says "load navi.gcimg".

Exactly. It's easy to detect when the game is trying to read certain data from the disc, but we have no idea about which data on the disc corresponds to which file in the texture pack. If Dolphin is going to support anything like that, the texture pack would need to provide mappings for it, and that would involve quite a bit of work from the texture pack makers.

(09-29-2015, 03:06 PM)Shonumi Wrote: Something more straightforward would be to load a texture from your HDD/SDD or whatever as soon as texture data hits Dolphin's emulated VRAM and is properly hashed. But you'd still come across (or at least run the risk of) stuttering due to an I/O bottleneck. That would only potentially solve the issue of consuming massive amounts of RAM during gameplay.

That's pretty much what currently happens when prefetching is disabled.

(09-29-2015, 03:06 PM)Shonumi Wrote: Here's a crazy idea that would be an absolute pain to implement, but I think it has some merit. If Dolphin could somehow assign certain textures a priority level, certain textures could be loaded on startup, while others are loaded dynamically as they are encountered in the game. It would probably be something best left to the people making texture packs (they can pick and choose common ones, or do a 50/50 type deal). They could chose smaller textures or lesser used textures to be loaded dynamically.

Maybe? I'll keep this in mind in the future.

[phly95]

(09-29-2015, 03:46 PM)mimimi Wrote: Isn't decoding the textures the main problem? I mean decode from bmp, png or whatever to the format that is actually used by the GPU? So one step forward could be to do decode all textures at startup, and write them decoded to disk. Then you only need a fast HDD or just a SSD to load, and it should lag less.

You are 100% right. I actually tried making a RAMdisk with the texturepack on it (using folder junction as dolphin doesn't normally let you do this) and it still stuttered exactly the same amount, because it was decoding. Maybe this is the first thing we should request as decompression is already implemented, but it just needs to go to disk instead of RAM.

[AnyOldName3]

I've said this before, but it might be a good idea to add some level of support for one of the lossless (and maybe some lossy, too) DDS formats in the master branch. Any modern GPU can decode them practically instantly in hardware, and it means we don't need to potentially write out tens of gigabytes for every texture pack. Alternatively, something a bit like Ishiiruka's async shaders might work - we could use the vanilla texture while we wait for the custom one to decode.

[phly95]

(09-29-2015, 11:34 PM)AnyOldName3 Wrote: I've said this before, but it might be a good idea to add some level of support for one of the lossless (and maybe some lossy, too) DDS formats in the master branch. Any modern GPU can decode them practically instantly in hardware, and it means we don't need to potentially write out tens of gigabytes for every texture pack. Alternatively, something a bit like Ishiiruka's async shaders might work - we could use the vanilla texture while we wait for the custom one to decode.

Well, also adding an option within dolphin to decompress to HDD could work as well as it would be using our own disk space and not someone else's bandwidth. HDD space is pretty much disposable these days anyway.

[AnyOldName3]

But SSD space is not, and people who still have their documents location in the default location might not appreciate a tenth of their SSD space being eaten.

[phly95]

(09-30-2015, 09:49 PM)AnyOldName3 Wrote: But SSD space is not, and people who still have their documents location in the default location might not appreciate a tenth of their SSD space being eaten.

It's still a personal choice, and of course, you could have both the option to convert to fast-decoding formats or uncompressed, so both sides have something. I actually have an SSD in my laptop, but I game on my desktop, and tbh, almost all the space I have used up on my laptop SSD is filled with HD TV series (77 GB right now). But actually, by desktop does have 2 HDDs that are both 2 TB in addition to the OS SSD, and using Windows 10 extended partition, it works like a single HDD. I'm sure a lot of gamers have a setup like that, and Dolphin doesn't run well on low-end hardware to begin with.