How Do You Suppose PS3 Will Provide Backwards Compatible

Part of the reason not to believe GS will be present. KK's categorically denied the presence of eDRAM. Unless they tried palming it off as texturecache or something on RSX, and hence 'it's not really eDRAM', they can't have included eDRAM in the system without KK talking porkies. And if they did include the GS+eDRAM but didn't incorporate the eDRAM into PS3's operation that'd be a waste. 48Gb second local storage to the GPU would be very nice I'm sure!

I'd expect compression of dta over the existing RAM would do well enough to accomodate PS2's BW demands.

 

I think we've all done similar kind of stuff, my last game also overlaps a bunch of offscreen and texture buffers in the same address range via time-sharing as well as moving main backbuffer around the memory mid-frame at some times.
My point was that generally we wouldn't want to touch stuff outside backbuffer for changing resolution anyhow. So what if reflections and shadowmaps are still rendered at 128x128 or whatever, or motion and glow blurs are still computed at 1/8 the SDTV res - the increased resolution of the backbuffer will still make things look nicer.

Btw, GTs 1080i is a field render with horizontal scaling through CRT, at worst it needs a couple of extra lines over what you render normally (540 instead of 512/448). The only trick to it is of course running the game at 60hz.

Right, it's the GS lacking proper miplevel selection, but because of it, there's also a lot of PS2 games (especially early on) that have simply forgone the use of mipmaps.
Anisotropic would help this at least a little - and it would also help with titles that do mipmap, since the per-object mip-coefficients are only 'correct' on certain polygon angles(usually screen facing).

Emulator does 'know' what the number of mipmaps and offset mip-koefficient are - I wasn't suggesting we'd just toggle the mipmap computation on and pray the default parameters will somehow work with PS2 games.
And yes, there may be some exceptions that will still fail - but that's no different then the occasional issues with enabling bilinear on PS1 games. It won't always work right - that's why it's optional.

Ken was talking about storing DVDs on some network storage and then "aging" them - basically running them through fancy offline scaling processing, converting the MPEG2 into some auto-magic generated HDTV stream.
While it generally makes things a little better, having it fully automated is hardly any guarantee it will always do things right.

 

Usually, the front and back buffer are swapped every frame, so you can tell where both are.

 

As long as certain effects are switchable in the Bios, like PS1's Smooth Textures and Double CD speed were optional improvements on PS2 that could be disabled if they stopped a game running, there's no worries.

 

Hmm.. our more recent PS2 titles have rendered to a single 32-bit back buffer, with a convert to 16-bit for the actual front buffer (it's difficult to tell the difference most of the time, and it gives back a fair amount of VRAM).. I guess this would be handled by your approach, as it would seem unlikely that those primary buffers move around during the game (ok, maybe for FMV playback and so on.. but not in gameplay), yes?

Other GS things that concern me with an emulated approach are the alpha fillrate, which - frankly - is poor on the NV4x series. And finally, the bizarre texture format hacks that you can do on PS3 (doing channel swaps.. the kind of stuff you do when tonemapping, or doing that hacky Dot3 implementation).

On the EE side, I'd be worried because most of CELL's power comes from immense FPU performance. Unfortunately, PS2's FPU and VU0/VU1 use non-standard (ie not IEEE compliant) floating point behaviour - whereas CELL/SPEs are IEEE compliant. I can't imagine them being able to make use of the FPUs on CELL to accelerate PS2 floating point emulation, as the results will be incorrect. Leaves them emulating PS2-style floats with integer ops, wasting most of the machines performance.

Challenging, to say the least!

 

SPE's SP floating point units are NOT fully IEEE compatible or they are about as much as the VU's SIMD array. I think you are getting confused with the SPE's DP FP support.

The problem comes from the fact they use Fused-Multiply-Add's and not FMAC's (not centered around the idea of the ACCumulator register) so some instructions will have to be emulated.

 

Haven't Sony announced a plan to spend $1,1 billion on 65 Nm-process lines in their Nagasaki plant? That's the place were they manufacture the EE+GS chip plus the Cell processor, right?

Seems possible to me they start out their 65 Nm process with the EE+GS chip and later on the cell processor.

 

Well, according to what King Kenny said, it will be a combination of hardware and software. There is no such thing as hardware emulation without actual PS2 hardware (or another piece of hardware) in the box dedicated to b/c, otherwise it's all software. The way I see it, I don't see Cell/RSX doing any major EE/GS emulation in software. The overhead makes it impractical. So I see a 90nm EE/GS a la PSTwo in the box that handles all of the PS2 emulation while the PSX emulation is handled in software. The PSX games will therefore be enhanced while the PS2 games look the same.

Perhaps the EE/GS combo won't be idle while playing PS3 games and will be used as an I/O controller for broadband functions.

 

No.. I'm not confused about DP support. That is of no concern, as PS2 has no DP support to emulate.. but you're right, in that PPU/SPU are not fully IEEE compliant. But they are more compliant than the PS2 VU/FPU implementation. Their behaviour relating to things like divide-by-zero, for example, where on PS2 VU/FPU you'll get zero, yet on PPU/SPU you'll get NaN.

 

they might go to a similar route they did with the ps2/ps1 compatibility...

the ps2 had the ps1 chip as its IO chip if i remember correctly...




maybe the ps3 will have the EE as an IO...

and have the rsx use its pixel pipes as an "emulated GS pipes"

the ps1 will be software emulated on the ps3 more likely