Question about PS2 pushing texture on the bus ondemand??

[Jov]

Was reading an interview by IGN with Bioware devs back in late 2000. The following is something I've always wanted to know in detail:

Reverend-IGN Tech fun again!: In the last chat you said that low video RAM was limiting things like the textures and anti-aliasing. Isn't there some way you can take some Main RAM and assign it to be video RAM? And if not, why?

DavidBioWare Yes, the video memory situation has improved dramatically since last time.
DavidBioWare The problem was that there was too little video memory to fit all our textures, and the machine can't use a texture unless it's specifically in video memory.
DavidBioWare What we've found since then is that the PS2 has enough bus bandwidth to transfer each texture from main memory to video memory as it's needed.
DavidBioWare That's on the order to 100s of Mb per second. We hadn't anticipated that the PS2 had that kind of brute horsepower on its bus. No other machine I've used does, including any PC or the Dreamcast.
DavidBioWare We had to reorient our thinking after that. So now we have almost more texture memory than we know what to do with.

Given this reoriented approach provides more texture memory, then why is it that most PS2 games today still suffer from lowres texture and/or lack of [F]AA compared to the other console platforms??

Is it because 100s of Mb/sec still doesn't cut it? Or is it due to the weaker MIPs core in feeding the GS?

Some PS2 dev input would be appreciated.

(My apologies if this was covered in previous threads. Its late and the bed looks welcoming )

 

[Paul]

The VRAM is lacking, any way you cut it.

 

[London Geezer]

Because, even using main RAM, which is what everyone's doing, there is only so many uncompressed textures you can fit in a tiny 32MB Ram...

RE: AA, it's all about the Vram. In that case, it's the Vram that's lacking. Not enough room to store big frame buffers. Hence, low resolution and no AA. Usually.

 

[Jov]

The VRAM is lacking, any way you cut it.

Doesn't the bus between the EE and GS have enuff bandwidth to push an entire frame to the 4MB VRAM using it as Front Frame Buffer?

Or better yet split the 4MB VRAM into 2/2MB for front/back Frame Buffers, and use the 2MB front FB similar to the GC's 2 MB FB?

 

[London Geezer]

The VRAM is lacking, any way you cut it.

Doesn't the bus between the EE and GS have enuff bandwidth to push an entire frame to the 4MB VRAM using it as Front Frame Buffer?

Or better yet split the 4MB VRAM into 2/2MB for front/back Frame Buffers, and use the 2MB front FB similar to the GC's 2 MB FB?

It's a bit more complicated than that, but i'm sure there are loads of people on here who can explain this much better than i can ever dream of.

 

[Jov]

Because, even using main RAM, which is what everyone's doing, there is only so many uncompressed textures you can fit in a tiny 32MB Ram...

RE: AA, it's all about the Vram. In that case, it's the Vram that's lacking. Not enough room to store big frame buffers. Hence, low resolution and no AA. Usually.

Jak&Daxter streams its content from the DVD on demand, granted most textures are simpler, but this doesn't rule out the possibility of streaming highres texture as required and uncompressing them by the EE.

As for your 'RE: AA" comment, my analogy to GC applies. I know the PS2 and GC are different in how they handle graphics, but what is the limitations for the PS2 to utilise its 4MB VRAM as frame buffer similar to the GC's and do all its text and AA in main memory similar to GC and its 24 MB 1T-SRAM (granted its 10 ns)?

Is it because the 2560-bit bus (1024-bit read, 1024-bit write, and 512-bit texture) with a peak bandwidth of 48 GB/s is not cutting it?

 

[Jov]

It's a bit more complicated than that, but i'm sure there are loads of people on here who can explain this much better than i can ever dream of.

That's what I am interested in.

Well its late and my bed is calling, thanks for posting guys (looking forward to reading more replies).

 

[London Geezer]

Your analogy with the GC is kinda icky. There aren't that many games, if any, on GC that feature AA. Most of the games just run at a plain and simple 640x480 with just a flicker filter for interlaced output.

 

[vliw]

The things are not so difficult to understand, look at this picture:

Playstation 2 EDRAM is very fast but 4 MB is a little quantitative so you must think different, you can't put a lot of textures and render the scene, you must think and develop a technique to exploit the full potential of Ps2 architecture.
So you can send to GS, textures via PATH3 and in the same time compressed vertices through Vif, this is a very advanced technique but i think is very powerfull, the main difficult is synchronization about texures and primitive to render.
If your game works in full buffer imho this is the only valid choice because you need a lot of Frame Buffer memory and you have not so much space for stored textures.

Sorry for my bad english, i'm improving it now

 

[Guden Oden]

Sorry for my bad english, i'm improving it now

You're betatesting a new software upgrade for your neocortex, huh?

 

[Li Mu Bai]

Your analogy with the GC is kinda icky. There aren't that many games, if any, on GC that feature AA. Most of the games just run at a plain and simple 640x480 with just a flicker filter for interlaced output.

RL & RS3 both use FSAA. Same thing with the X-Box though. PGR2 & ?

 

[Jov]

Playstation 2 EDRAM is very fast but 4 MB is a little quantitative so you must think different, you can't put a lot of textures and render the scene, you must think and develop a technique to exploit the full potential of Ps2 architecture.

PS2 4MB VRAM is fast, but not fast enough to stream down texture ondemand for the draw buffer?

What are some of the current techniques used to exploit the PS2 over previous generation of games (I don’t expect much of a response given most devs would keep their IP close to their chest)?

So you can send to GS, textures via PATH3 and in the same time compressed vertices through Vif, this is a very advanced technique but i think is very powerfull, the main difficult is synchronization about texures and primitive to render.
If your game works in full buffer imho this is the only valid choice because you need a lot of Frame Buffer memory and you have not so much space for stored textures.

If better synchronization between the textures and primitives can be achieved, can higher res texture be utilized given the potential in saving due to the lack of misses?

It seems Full frame buffer is the way for most games if not all games these days. What say if you go back to half frame (with all its drawbacks), will there be much memory saved to provide higher resolution textures?

I think someone in the past here might have mentioned the saving is not worth the tradeoff, but can’t be certain?

Sorry for my bad english, i'm improving it now

I’m learning English (or Aussie) everyday!

 

[Sonic]

JOV, the bus from main memory to VRAM for the GS is only 1.2 BG/sec.

 

[Jov]

JOV, the bus from main memory to VRAM for the GS is only 1.2 BG/sec.

Did you meant the bus between the GIF and GS is 1.2GB/sec and not main memory to VRAM?

 

[Sonic]

Right. I must be a little rusty when it comes to PS2 hardware.

 

[Guden Oden]

Did you meant the bus between the GIF and GS is 1.2GB/sec and not main memory to VRAM?

There is no main memory to VRAM interface, all access goes through the GIF and its 1.2GB/s bandwidth. That's all there is.

 

[vliw]

GS is not connected directly to main ram, when you perform a DMA transfer and you want to send texures to GS you perform an Image Transfer trought the bus and send your texture to GIF, the interface between GS and the world behind the Graphics Synthesitzer.
The bandwidth between GS and GIF is 1,2 GB/s.
When we talk about hi-res textures the things to say is that you can use full 32 bit color textures but the problem is the same you don't have a lot of space and so you must do something else.
You can use clut, textures of 256 colors(8 bit so) and you can place a lot of 8 bit textures in a 32 bit texture( i think 150 textures fit well in a 32 bit image), this is because the GIF is optimized to transfer 32 bit textures.
Sure with 32 MB of EDRAM in the GS you can use a lot of beautifull 32 bit textures but you have only 4 MB and this is the main problem...imho....