They don't use 1280x1080 because that's WAY too many pixels above the usual 1280x720 mode. Performance would drop like a rock if developers went this route just for the sake of compatibility with 1080i HDTVs.
960x1080 is the closest rendering mode to 1280x720 in terms of total pixels rendered; that's the main reason most devs opt for this resolution in 1080i/p upscaled output mode. The memory difference between rendering a game in 1280x1080 versus 960x1080 is pretty miniscule (less than 500kb total).
No, because the PS3 doesn't HAVE a hardware scaler capable of "scaling directly to 1920x1080." If you want to scale directly like that on the PS3, you'd have to resort to implementing a software scaling solution to the game, which takes up way more memory than hardware scaling.
Again, you're confusing hardware-based scaling methods (which have zero memory and performance overhead) with software-based scaling methods which have considerable overhead in terms of memory required and extra performance for the scaling process done by the GPU.
I get the feeling we're talking about different steps of the pipeline.
#1: render; done at full 720p, i.e. 1280x720
#2:
software scaling to 960x1080
#3:
hardware scaling to 1920x1080
Step #3 is free for all intents and purposes, but on PS3 limited to horizontal expansion only, and on top of that requires one of only a handful of horizontal input widths to work (one of 960, [strike]1024, [/strike]1280, 1440, 1600 [strike]AFAIK[/strike] according to
this).
So the programmer choice is down to how to adapt render resolution into something that can feed step #3. If you want to output 1080 lines after a render with 720 lines, in absence of a vertical hardware scaler you have to do some software scaling. If you can't adjust rendering resolution to something fitting (with 1080 lines), #2 is a mandatory step. But you can still pick the horizontal target resolution produced by that step.
The easiest choice from the perspective of software scaler complexity is to keep the render width and just interpolate lines, i.e. produce 1280x1080 in this case. That's still a valid input to step #3.
So why not 1280x1080?
Is it because of compute throughput? No, because going from 1280x720 to 1280x1080 is a 1D filter and actually takes less compute resources than the 2D filter you need to shrink the lines to 960 width, too.
(bilinear interpolation: 3 vector MACs per output pixel; linear interpolation: 1 vector MAC per output pixel)
Is it because of memory bandwidth? Possibly, maybe ... not really. Writing 60 times 960x1080 pixels, assuming 4 bytes per pixel (which might be off by one), consumes 250MB/s of memory bandwidth. Do it in 1280x1080 and it takes 33% more, 332MB/s. Both are drops in the bucket of 19.2GB/s of GDDR bandwidth. You have to be teetering very close to the edge of acceptable performance to get pushed over by this incremental 82MB/s use of bandwidth, and even if it happens, all you get is a torn frame every once in a while, which may not be desirable, but won't make you fail QA.
So again, why not 1280x1080? Because it uses more memory.
Memory budgets are very hard lines. If all memory is already spent and accounted for, you can't push it another 1%. There's nothing left to use. There's no "we'll do it a frame later" if you require more space, as opposed to a search for more computation which is always a possibility and can be made to work, if a frame later.
TV sets labelled 'HD Ready' in the EU have no problem. Those marketed as 'HDTV' or somesuch could be bunkum. You have sets incapable of rendering 720p or 1080i sold as HD sets because they could receive a signal and display it on their under-resolutioned displays.
