If Sony had to use PS2 components to do a next-gen system...

[ShinHoshi]

Just suppose that for whatever reason, Sony needs to do a new machine (just to stop the others while PS3 is ready) and since they don't want to have high costs, they just choose to use PS2 components to build it.


For instance:

MIPS CORE. Since this is one of the biggest bottlenecks on PS2 they decide to do a dual core rated at twice the clockspeed.

VUs. They decide to add two more. VU0s just disappear and instead of them we have 4 legit VU1s.

GS. Not very sure what they could do here...Perhaps adding more bandwith and a higher clocking...plus more VRAM: let's say 12 MB VRAM.

Main RAM. Jumps to 128 MB.

Do you think that :

1. Would it be feasible ?
2. Would it give a reasonable performance for its price ?

If not, what would you propose ?

 

[Sonic]

Would these PS2 components be upgraded from the basic technology? You say a dual MIPS core with 4 VU's, that isn't bad but it should be a clockspeed fo 1 Ghz or more. A GS with say 32 pipelines instead of 16 would go nice with 12 MB of eDRAM, but it would also be nice to have texture compression and a much more feature rich GPU also. The bus to main RAM would have to be much higher and I'm thinking at least 12 GB/s for that one.

 

[ShinHoshi]

It was just an example...Basically I was thinking on changing the performance of them...not the functionality...
It's clear that a PS2 with a GS that had hardwired T&L+"free effects" would be much better...but that would imply major changes...

Anyways, you are right. Having 4 paths to GS would require more bandwith.

 

[Sonic]

Well, 32 pipelines with mroe bandwdith to the memory and more eDRAM would help solve a lot of the GS's problems. Devs would be able to do more things in software and have the games still be playable.

Maybe Faf can chime in on what he wishes this couldbe.

 

[cthellis42]

GSCube rebranded!

 

[Squeak]

Well I'm certainly no expert, but from what I understand, currently MIP mapping is one of the biggest hurdles to most PS2 developers (although I don't know exactly what the problems with it are).
If you had optimal MIP mapping and 2-3x overdraw, all you would ever need on a 640x480 display, would be in the region of 3-4Mb for textures (4Mb is enough for ~six 512x512x16 textures with MIP maps!)
So maybe a better MIP map implementation plus an additional 8Kb of texture cache, for double buffering and cheap trilinear?

Another feature I think would be nice on the GS, is the ability to store display lists, for more efficient multitexturing.

The next thing I would ad, is 16-32Mb of RDRAM for additional memory bandwidth to EE, or maybe alternatively a larger CPU cache (although that would be against the whole VLIW philosophy of the PS2).

 

[London Geezer]

I think VRAM from 4 to 32MB would help. 32 or more pipelines would help (given we can't put in "features" as the original poster said, we'd need even more fillrate to be able to afford advanced features that are now lacking from PS2). Increase the clockspeed 5-10 times would be feasible. also you could think of accing an arbitrary number of VU's... Not sure what one could do with the EE core... Increase the size of internal caches, which seem to be a big problem for many people. And put 512 MB RAM in there.

 

[Fafalada]

Maybe Faf can chime in on what he wishes this couldbe.

To be honest, I'm already too much in the whole 'nexgen/PS3 mode' to want to think about steps back.

If you wanted to rebrand old tech it'd probably be better served to use pixel pipelines from PSP GPU instead of GS, at least fixes the major issues. And sticking with lowfeature set, GSCube route would probably work best, a bunch of rendering nodes with layer composition at the end.

 

[archie4oz]

Hmmm... Don't know where to go with this one... I guess if you wanted a modern PS2.5 or something with reasonable backwards compatibility and familiarity...

For starters with Sony's currently available process, the I-32 would probably commercially viable (as long it's going back to a discrete processor), so and I-32 would be mandatory...

A full set of combiner ops (the standard 13-14 blend modes, hopefully as fast as the current alpha blending), a cleaner method for LOD calculation/MIPMAP selection, 12 or so MIPMAP levels instead of 6 (depends on if texture size support is increased), 2K texture support, more arbitrary non-pow2 texture support (probably not as necessary)... There's a lot more I'd like but I could just live with that.

One minor hack would be perhaps to increase the page buffers to like 64-128KB. Keep the 8K alignment for compatiblity and familiarity but hopefully eliminate some of the performance penalties (or reduce them) of the page breaks...

As for the EE, the modifications I think would be more drastic. For starters, lose the 5900 and go with a more robust core like the 20K or 24K (preferable the 20K), but keep some of the EE enhancements (128-bit GPRs (with 8 banks of shadow registers! ), MMI, UCAB, WBB, and of course other necessities like DMA, SIF, etc). This would give the EE a more robust core to work with, with REAL caches (32K/32K+256K L2, or do away with the L2 and incorporate 8-way 128K/128K L1s), and a real FPU as well (and keep MIPS-3D ASE from the 20K on it as well)... Increase SPRAM to around 128K and keep both VUs but make them symmetrical (well VU1 would not have Macro mode), and increase their mems to 128KB respectively. It'd be really slick if the VU's could DMA to themselves as well (dunno what significant changes that would incur)... And perhaps a hardware clipper somewhere in the GIF would be nice.

The IOP would be interesting... I've never seen an R3K over 80MHz, but I'd like it to be in the 100-200MHz range. Probably replace the LSI core with a Toshiba TX-19a or TX-39 core... You get the benefit of MIPS16e support and a more DSP like implementation. Plus you get a MeP friendly platform, so you can replace the GTE and MDEC with custom MePs to emulate that functionality and even more importantly have a lot more processing options in IOP mode...

Of course main ram would be upgraded to 128MB of at least PC1200 (perhaps quad channel as well), with the EE running around 1-1.2GHz and the GS running at around 300-600MHz... The WBB and UCAB (on the EE) would probably need deepening to deal with the longer latencies though... Probably up the IOP and SPU ram to 8MB each as well...

Well that's my ¥2

 

[ShinHoshi]

Wow archie...You completelly changed the R5900 core...
Anyways, my purpose was to see mainly what was opinion regarding PS2 components and their scalability...
At what expense would those improvements come ? And the other question is if they would give a significative performance for the price...

I think that it would be more cheap to just use a bunch of old components (for instance VUs) than to increase their performance (for instance making the MIPS core running at 4Ghz). And the same happens with the GS...

 

[archie4oz]

Wow archie...You completelly changed the R5900 core...

Why not? You're just applying the same EE "enhancements" to an R20K core... Both the R5K and R20K belong to the MIPS64 family anyways so it's not as much of a leap as you think... It would be more sensible than to try to bubblegum and helicopter tape enhancements to the current EEcore.

Actually I'd forgotten about the IPU as well, although Faf could elaborate more on it...

I think that it would be more cheap to just use a bunch of old components (for instance VUs) than to increase their performance (for instance making the MIPS core running at 4Ghz). And the same happens with the GS...

You mean just like piling on more VUs? Why, that would simply make things more complicated (you'll need to upgrade the DMA controller to support them anyways) and you're already CPU bound anyways, and you want to tie the CPU down even more building more complicated DMA chains?

It's clear that a PS2 with a GS that had hardwired T&L+"free effects" would be much better...but that would imply major changes...

Why would I want a hardwired T&L on the GS? How capable would it be? How many hardware lights? what kind've lights? what sort of throughput? what sort of features, decent vertex blending? I'd rather just have a really fast clocked symmetrical VU0/VU1 with more memory and a hardware clipper (even toss the clipper if it prevented 1GHz from being reached)...

 

[ERP]

The problem is that you have to address the bottlenecks, before you can scale the performance.

It would be a waste of time adding VU's without first dealing with the MipsCore. They'd just be starved for data.

As it is the GS is largely sitting idle in most PS2 games.

Increasing the clock on the Mips core wouldn't even solve the main issue, it spends most of it's time waiting for data from memory anyway. It needs a decent sized L2 cache and then you need to increase it's clock rate.

Once you've done that you can start scaling up your VU's, but you'll need someway to synchronise vertex streams from them. Then you need to address the bus bandwidth bottleneck.

Finally you can think about upgrading the GS which IMO should just be junked in favor of something with a half decent feature set.

If you read the Cell patents with a particular slant, you can read it as each processing Element is actually just a super EE, replace the Mips core with a PowerPC unit and slap on 8 VU's. Of course they try to solve some of the architectural shortcomings at the same time. Of course looking at it this way makes it sound a lot less sexy

 

[Fafalada]

Ok ok, you've tempted me to post again
I actually like Archie's idea of switching R59 for something better - you retain compatibility and fix all of the majort shortcomings of the current core in one sweep.
Higher clocked VUs with some fixes sounds more reasonable then just bolting more of them - more VUs would involve far more radical changes to entire system, EE included, as ERP and Archie already explained.

Anyway, to go to stuff that wasn't touched much yet - we're revising GS (I-32 version).
I want twin buses from external memory.
One will be 128bit for vertex and state data, and this time fix the input format without the fixed point hackened stuff. Also - input data is now in H-space, even if we don't include clip, unified data would help. We rip the pixel pipes from PSP as I've said already (hey, it's still reusing existing tech ).
Clocking the whole thing to 300-600mhz sounds good.

Second bus can stay 64bit, and will be texture only. The novelty is that we bolt a couple of IPUs on the GS this time, sitting between external input and MemIF.
This way you keep data compressed on the buses, but decompress before actual eDram write (not on demand, it's still manual uploads as before).
The IPU is fixed a bit too - I want single path conversion to quantized output, no more nasty feedback schemes for that.
Also, expand quantization scheme to support 2x2/2x1VQ (on GS also).

 

[Vince]

Clocking the whole thing to 300-600mhz sounds good.

IIRC, The I-32 Graphic Synthesizer already ran upto 600MHz at 180nm.

 

[archie4oz]

IIRC, The I-32 Graphic Synthesizer already ran upto 600MHz at 180nm.

Maybe in a freezer and not requiring consistent/accurate output... The highest I've ever seen any GS run (used for process validation) was 300MHz (@130nm (hence why I started my *wishes* there))... Dunno if it would go faster reliably, but it would be nice....

 

[Vince]

Khan described a 0.18-micron chip designed with Sony Computer Entertainment, the GS I-32, that contained 287.5 million transistors and ran up to 600 MHz. "We think the transition from VLSI to SoC is enabled by a hierarchical design approach," said Khan. "The major change in our methodology was to go to fully hierachical timing."

Using a fully hierarchical approach, said Khan, allowed this chip to go from netlist to tapeout in 10 weeks. He said that hierarchical block-level timing analysis provided a "scalable" capability that matched the high complexity of the chip.

To make hierarchical timing work, however, Altius developed a new technology for delay calculation and estimation. Khan described this new technology as a "nonlinear current source model" that computes delays based on the actual loading of nets, as opposed to using a lookup table. He said these models come within 2 percent of Spice accuracy.

I knew I remembered seeing this.

 

[Paul]

Khan described a 0.18-micron chip designed with Sony Computer Entertainment, the GS I-32, that contained 287.5 million transistors and ran up to 600 MHz.

......This goes to show you how insane the PS3 graphics IC is going to be if this thing could clock to 600 and contain 32mb e-DRAM. Than again I'm sure this thing was huge, but the PS3 VS will also be a huge part. Anyone got the exact area of the I-32?

 

[J-A-S-D-F]

Screw that... Have any of you thought about how feasible this would be? Why would people throw out $250+ for a PS2.5 only to be replaced within 20 months? Why would developers choose to develop for it if its lifespan would only be ~ 20 months? It would be just too ignorant to do such a thing.

 

[London Geezer]

Screw that... Have any of you thought about how feasible this would be? Why would people throw out $250+ for a PS2.5 only to be replaced within 20 months? Why would developers choose to develop for it if its lifespan would only be ~ 20 months? It would be just too ignorant to do such a thing.

That wasn't the point of the thread..... But hey you didn't get it then, not sure u're gonna get it now...

 

[ShinHoshi]

Screw that... Have any of you thought about how feasible this would be? Why would people throw out $250+ for a PS2.5 only to be replaced within 20 months? Why would developers choose to develop for it if its lifespan would only be ~ 20 months? It would be just too ignorant to do such a thing.

We were just discussing how it could be that PS2 2.5 not if it would be wise or not to create and release it. Anyways I would like to see that kind of design. A PS2 with more power but with some of their main failures solved.
I am very pleased with what PS2 has done with its hardware philosophy so why not just take it to a higher level ?