PS2 question

[Tagrineth]

Those games were probably meant to be played using the composite cable which could blur dithering dots enough for them to be not annoying. It's really obvious when you play PSX games on PS2 with component cable, though.

It's often visible on my old RF-only TV which bleeds horribly at this point.

 

[Fafalada]

Poor blending would seem like a really stupid oversight on a system that relies so heavily on multipass texturing, is it really true? How many blend modes are there anyway, isn?t alpha more or less just alpha?

Well there is the most glaring complaint, especially on this board - the lack of DOT3 blend.
There is a few others that would be nice to have, although more for comfort then real necessity, but that's exactly why it would be "nice" to have them.

The filtering I don?t know about, mip banding never bothered me much and the other two consoles can?t really effort to do anisotropic filtering, so is the PS2 lacking that much?

GS Mipmapping implementation is a bit strange, as well as complicated to work with when you first use it.

"IPU does it on the fly to generate IDXT8". Forgive me for not being au fait with all the PS2 acronyms but, at a guess, that sounds like MPEG HW.

One of the functions of IPU(the MPEG2 unit) is also quantization of texture maps, yes.

I mean, here we have disscussion here, about CLUT vs VQ vs S3TC and the winner is like S3TC -> VQ -> CLUT.

Simon said it - I'll agree. In practical terms, both GC and PS2 would be more competitive with XBox using VQ over S3TC.

 

[andypski]

Simon said it - I'll agree. In practical terms, both GC and PS2 would be more competitive with XBox using VQ over S3TC.

I understand about PS2, but how would GC be more competitive using VQ over S3TC?

 

[PC-Engine]

Simon said it - I'll agree. In practical terms, both GC and PS2 would be more competitive with XBox using VQ over S3TC.

I understand about PS2, but how would GC be more competitive using VQ over S3TC?

Probably memory footprint.

 

[ERP]

Well there is the most glaring complaint, especially on this board - the lack of DOT3 blend.

This isn't the blending mode I was thinking of when I made the statement, but I'll agree it would be a nice addition if they supported all the basic blending modes first.

 

[Colourless]

Am I mistaken if I were to say that PS2 can't do Multiplicative SRC*DST blending?

 

[phat]

Am I mistaken if I were to say that PS2 can't do Multiplicative SRC*DST blending?

It can. What it can't do easily is sum up the component-wise products to make a dot-product, and it doesn't handle signed multipliers well. That's why dot3 bumpmapping on PS2 needs something like 6 or 7 passes. One pass for each colour component and each +ve and -ve case, for 6 passes, plus another "put it all together" pass, as I recall. Expensive on fill-rate, but the GS has fill-rate to burn.

 

[London Geezer]

Am I mistaken if I were to say that PS2 can't do Multiplicative SRC*DST blending?

It can. What it can't do easily is sum up the component-wise products to make a dot-product, and it doesn't handle signed multipliers well. That's why dot3 bumpmapping on PS2 needs something like 6 or 7 passes. One pass for each colour component and each +ve and -ve case, for 6 passes, plus another "put it all together" pass, as I recall. Expensive on fill-rate, but the GS has fill-rate to burn.

i guess it does, so why are we not seen it. anywhere. not even demos. not even real time cut-scenes... it's just a shame. if it can be done, then it should be used sometimes... i dont expect xbox levels of DOT3 but at least a bit...
i'd be happy even with just Detail Maps used more often than.. well... NEVER really...

 

[ERP]

Am I mistaken if I were to say that PS2 can't do Multiplicative SRC*DST blending?

It can. What it can't do easily is sum up the component-wise products to make a dot-product, and it doesn't handle signed multipliers well. That's why dot3 bumpmapping on PS2 needs something like 6 or 7 passes. One pass for each colour component and each +ve and -ve case, for 6 passes, plus another "put it all together" pass, as I recall. Expensive on fill-rate, but the GS has fill-rate to burn.

Perhaps you'd like to elaborate on the exact blending mode you would use to do Src.color * Dst.color........

 

[phat]

Am I mistaken if I were to say that PS2 can't do Multiplicative SRC*DST blending?

It can. What it can't do easily is sum up the component-wise products to make a dot-product, and it doesn't handle signed multipliers well. That's why dot3 bumpmapping on PS2 needs something like 6 or 7 passes. One pass for each colour component and each +ve and -ve case, for 6 passes, plus another "put it all together" pass, as I recall. Expensive on fill-rate, but the GS has fill-rate to burn.

Perhaps you'd like to elaborate on the exact blending mode you would use to do Src.color * Dst.color........

Oops. I miss-recalled. I forgot that while A, B, and D in the blending formula, (A - B) * C + D, are colour vectors, C is only a scalar (such as alpha). For some reason I had it in my head that the * in the formula was a component-wise multiply.

Whether or not C can be a colour vector doesn't change the number of passes required to emulate dot3 on the GS, which is probably why I didn't remember that it can't be a colour vector.

 

[marconelly!]

It can. What it can't do easily is sum up the component-wise products to make a dot-product, and it doesn't handle signed multipliers well. That's why dot3 bumpmapping on PS2 needs something like 6 or 7 passes. One pass for each colour component and each +ve and -ve case, for 6 passes, plus another "put it all together" pass, as I recall. Expensive on fill-rate, but the GS has fill-rate to burn.

Wasn't it four passes? I remember it from that document which outlined how DOT3 can be done.

 

[Fafalada]

andypski,
GC has less fast memory available then PS2, and both have considerably less then XBox either way. The more efficient the compression, the better - hence 2x2VQ would work better

That's why dot3 bumpmapping on PS2 needs something like 6 or 7 passes. One pass for each colour component and each +ve and -ve case, for 6 passes, plus another "put it all together" pass, as I recall. Expensive on fill-rate, but the GS has fill-rate to burn.

In that particular case you need +- comb. for each case too, so 12 passes total. But that's from the paper describing OGL implementation on TNT series cards.
On PS2 it's modified using framebuffer operations for final combines, so you're actually doing 'only' 4 texture passes, get intermediate results in each R,G,B and adding them together as a fixed FB operation in the end.
The technique isn't all that useless if you use it with paralel lights and terrain though - it comes down to 2 passes.

This isn't the blending mode I was thinking of when I made the statement, but I'll agree it would be a nice addition if they supported all the basic blending modes first.

Well that's why I said 'on this board' Although, afaik most people complained about missing color multiplies, something I haven't exactly missed (I would miss it a whole lot more if I had dot3 to play with though).

What I did bitch about often is the complete lack of alpha modulation - especially if it could be specified separately from RGB.

 

[Wildstyle]

Tagrineth,

The textures have to move a lot more because GC has *less* space. It's also invisible to the developer, so I doubt it's as efficient as PS2's cache either.

Sure it is. But the maximum efficiency - texture compression ignored for a moment because the two consoles use totally different formats - of a 1MB cache will be half that of a 2MB cache (they have comparable bandwidth... 9.6 vs 10.4)

Hmm so generally then what would be the effiency of the GC's texture cache compaired to the Ps2's? and also on the last part of the last quote were you trying to say the the GC's texture cache would be like 5.2gbs half of it's bandwidth compaired to the Ps2's 9.6gbs of bandwidth because of the Ps2 haveing 2mb compaired to the GC's 1mb?

 

[Tagrineth]

Tagrineth,

The textures have to move a lot more because GC has *less* space. It's also invisible to the developer, so I doubt it's as efficient as PS2's cache either.

Sure it is. But the maximum efficiency - texture compression ignored for a moment because the two consoles use totally different formats - of a 1MB cache will be half that of a 2MB cache (they have comparable bandwidth... 9.6 vs 10.4)

Hmm so generally then what would be the effiency of the GC's texture cache compaired to the Ps2's? and also on the last part of the last quote were you trying to say the the GC's texture cache would be like 5.2gbs half of it's bandwidth compaired to the Ps2's 9.6gbs of bandwidth because of the Ps2 haveing 2mb compaired to the GC's 1mb?

Well, speaking realistically, GCN's texture cache is probably a good deal more efficient thanks to S3TC.

But wrt bandwidth, it depends how many textures are used. I said that without thinking of GCN's virtual texturing, for one, and ignoring S3TC.

Anyway, it all just depends on the number of textures used - let's say you have exactly 2MB of textures. On the PS2, you can throw them straight onto the cache and not give it a second thought, but on the GCN they would have to move around a whole bunch because they don't all fit in at once.

But again, GCN has virtual texturing and S3TC which make its texture cache, for all intents and purposes, 6MB with 60GB/sec.

 

[Simon F]

I have some complaints regarding nomenclature:

To me, a (processor) cache implies a storage unit that has some form of automatic management of its contents (eg LRU replacement policy) and a means of transparently addressing that data. In fact, the cache can often be totally invisible functionality-wise.

A scratch pad, OTOH, is something that has to be actively managed by the software and addressing is not automatic.

I would probably categorise the PS2's GS memory (well the bit dedicated to textures) more as as a scratch pad buffer rather than a cache <shrug>

 

[jvd]

whats the latancy on both systems texture ram ? that would make a huge diff too .

 

[Fafalada]

Simon,
I'd agree, the 4mb in GS is a scratch pad. There are actually several other small caches between rasterizer and eDram.
In GC's case the 1mb buffer is it (no other layers between the rasterizer afaik). Although it IS true that it can effectively function as both SPR and cache at the same time, if programmer so desires.

But again, GCN has virtual texturing and S3TC which make its texture cache, for all intents and purposes, 6MB with 60GB/sec

Which is true for GS using 4bit/texel formats too, not that it matters though.
The effective bandwith number is silly though - rasterizer performs at peak speed regardless of format used (the only exception being 32bit trilinear).

 

[Teasy]

Which is true for GS using 4bit/texel formats too

But then the problem with that is you can't use 4bit CLUT anywhere near as widely as you can use S3TC.

I second jvd's question. What is the latency for GC and PS2's texture cache/scratch pad buffer? Doesn't GC use 1T-Sram for its embedded memory? If so that stuff is very low latency isn't it?

 

[jvd]

Which is true for GS using 4bit/texel formats too

But the problem with that is you can't use 4bit CLUT anywhere near as widely as you can use S3TC.

Also I second jvd's question. What is the latency for GC and PS2's texture cache/scratch pad? Doesn't GC use 1T-Sram for its embedded memory? If so that stuff is very low latency isn't it?

I dunno but i do know that lower latancy is much more important than a few mhz faster or a mbs faster transfer.

 

[Squeak]

Which is true for GS using 4bit/texel formats too

But then the problem with that is you can't use 4bit CLUT anywhere near as widely as you can use S3TC.

Can different textures use the same CLUT? In some games that would bring the bit per texel count down a lot.

I second jvd's question. What is the latency for GC and PS2's texture cache/scratch pad buffer? Doesn't GC use 1T-Sram for its embedded memory? If so that stuff is very low latency isn't it?

I’ve heard the buffers on both GS and Flipper consists a large pool of DRAM with a small amount of SRAM as a kind of cache. So they should be about the same in latency. GS DRAM mem-cells probably takes up more space though.

What I would like to know is the latency and set-up of buffers on NV2A and also the latency of main mem on xbox.