Wii RAM latency question

[Megadrive1988]

Unlike the GameCube, the Wii has two different pools of system memory. 24 MB 1T-SRAM plus 64 MB GDDR3.

Since these two types of memory have, AFAIK, different latency specifications, does this cause any problems, or any inconsistencies since 1T-SRAM is lower-latency while GDDR3 is (I think) higher-latency?

Or does this not matter, since their seperate pools and are treated seperately/differently?

 

[paawl]

I'm certainly not an expert in Wii programming, but I doubt that the differing latencies should pose any problems because the two pools of RAM are largely for different purposes. Just as the RDRAM and GDDR3 in the PS3 are for different purposes (and have different latencies), I assume that the GDDR3 in the Wii is used mainly for storing textures, where a higher latency is tolerable, while the 1T-SRAM is used for system memory, where a lower latency can have a big impact on performance.

The GameCube also had two pools of RAM, the 24 MiB of 1T-SRAM, and 16 MiB of "ARAM" (low-bandwidth SDRAM) for storing audio sample data. In the Wii, the 16 MiB of ARAM was replaced with a much higher bandwidth pool of 64 MiB of GDDR3 for use as "VRAM".

 

[forumaccount]

I'm not sure what kind of problems you're interested in, but...

The difference in latency is definitely something one needs to be mindful of when developing on Wii. Many tasks run significantly faster when their data is in the smaller bank, so the challenge is maximizing the usage of that bank and not using it for data that would work just as well in the slower one (such as textures).

One challenge here is that code resides in the smaller bank, meaning that when one loads a debug executable there can be a large amount of this bank used up by the code. Even if one makes a shippable version of the executable much much smaller than the debug version, it's a challenge utilizing the memory made up by this for assets. If it's not done carefully, it can be a nightmare making sure everything fits under every build condition.

 

[Panajev2001a]

I'm not sure what kind of problems you're interested in, but...

The difference in latency is definitely something one needs to be mindful of when developing on Wii. Many tasks run significantly faster when their data is in the smaller bank, so the challenge is maximizing the usage of that bank and not using it for data that would work just as well in the slower one (such as textures).

One challenge here is that code resides in the smaller bank, meaning that when one loads a debug executable there can be a large amount of this bank used up by the code. Even if one makes a shippable version of the executable much much smaller than the debug version, it's a challenge utilizing the memory made up by this for assets. If it's not done carefully, it can be a nightmare making sure everything fits under every build condition.

Isn't this a good reason to have more 1-T SRAM (main, smaller bank) on devkits than regular consoles? Do you mean to tell me it is not the case on Wii devkits?
If so... ouch...

 

[Brad Grenz]

The 1-T SRAM is not easily expanded.

 

[forumaccount]

Isn't this a good reason to have more 1-T SRAM (main, smaller bank) on devkits than regular consoles? Do you mean to tell me it is not the case on Wii devkits?
If so... ouch...

In general... I'd prefer not to have 2 banks. Then I wouldn't have to worry which of the two, if any, was larger on a devkit.

 

[Panajev2001a]

In general... I'd prefer not to have 2 banks. Then I wouldn't have to worry which of the two, if any, was larger on a devkit.

You must have loved GBA programming (NDS seems to be even worse on that front).

 

[Teasy]

Didn't the GameCube Dev Kit have 48MB of 1-T SRAM?

 

[Mat3]

Anyone know what kind of 1t-sram was used? 1t-sram-r or 1t-sram-q?

Edit:
I was able to find a source saying it was the R version. Seems like a strange choice.

 

[DeadlyNinja]

I just discovered something interesting (I think).

Those guys making the gorgeous Overlord Dark Legend claims they fit everything into 64MB.

Ric: The level of detail that we’ve got on Wii is probably unparalleled at the moment. It’s thanks to the engine that we’re using, but it also is thanks to the techniques that we’re using, as well. We’re using a lot of instant shading, we’re doing visual calling, so when you go around corners things are added on the fly. We’ve managed to pack in an abnormal amount of data in only 64 MB around, so it’s quite an accomplishment.

Why 64MB? That's just the GDDR3, what about the other 24MB? Why aren't they using that?

http://www.revogamers.net/articulos-394-Dentro-de-Overlord:-Chat-con-Climax-3.html

Lots of tech talk in that link.

I've very excited about Overlord. I have it on PC, and loved it.

 

[MDX]

I just discovered something interesting (I think).

Those guys making the gorgeous Overlord Dark Legend claims they fit everything into 64MB.



Why 64MB? That's just the GDDR3, what about the other 24MB? Why aren't they using that?

http://www.revogamers.net/articulos-394-Dentro-de-Overlord:-Chat-con-Climax-3.html

Lots of tech talk in that link.

I've very excited about Overlord. I have it on PC, and loved it.

Well I've been wondering about this for a while. Ever since it was stated that the 64MB OF GDDR3 could be accessed by both the CPU and the GPU. Its like a developer can take two approaches making a game on the Wii- like the Gamecube, primarily focusing on the 24MB, or like the Xbox, focusing primarily on the 64MB.

Its also why undoubtably the Wii could easily do HD by using a portion of the 64MB for the framebuffer like you would with the Xbox or even the 360(?).

 

[Shifty Geezer]

Its also why undoubtably the Wii could easily do HD by using a portion of the 64MB for the framebuffer like you would with the Xbox or even the 360(?).

PS3 and XB360 can barely do HD on occassions, so why try to get 3x the resolution out of Wii?? Unless 10 fps update is acceptible, the resources aren't there ot drive an HD game.

 

[forumaccount]

Those guys making the gorgeous Overlord Dark Legend claims they fit everything into 64MB.

Why 64MB? That's just the GDDR3, what about the other 24MB? Why aren't they using that?

Executable code will use up one-third to one-half of that 24MB in the average Wii game, or more depending on how it's designed and how badly they needed that memory for other things. There's some stuff every Wii game needs in memory too... I think it's up to 2MB depending on how clever you are about it. Throw in some stream buffers and you get pretty close.... assuming exactly 64MB of assets you're going to need them split between the two banks to some extent anyway.

 

[Teasy]

PS3 and XB360 can barely do HD on occassions, so why try to get 3x the resolution out of Wii?? Unless 10 fps update is acceptible, the resources aren't there ot drive an HD game.

Depends on what other graphics features you're using, the fillrate is there for that kind of resolution. I'm sure they could put some of the more basic Wii games in HD with little trouble, pretty pointless but they could do it.

 

[fearsomepirate]

You'd only be able to do anything in HD if you're allowed to draw directly to main RAM and bypass the eDRAM, or maybe do some kind of tiling. Also, the output hardware has to allow it.

 

[Squeak]

Executable code will use up one-third to one-half of that 24MB in the average Wii game, or more depending on how it's designed and how badly they needed that memory for other things. There's some stuff every Wii game needs in memory too... I think it's up to 2MB depending on how clever you are about it. Throw in some stream buffers and you get pretty close.... assuming exactly 64MB of assets you're going to need them split between the two banks to some extent anyway.

I don't know what kind of code you're writing or in what language, but one third is quite ridiculous not to mention one half.