PSP question

The FPU can only peak at 0.6+ GFLOPS: it should be no more than a standard FPU with FP MADD support ( FMA + FDIV ).

The VFPU would peakr at 2.6+ GFLOPS using a 4-way Vector MADD every cycle.
So you are thinking in 2fpi/cycle for a especial FPU ? I see... I was thinking in using the VFPU in paralel for independent FP calculations.

Edit:

Now that I think in it this is a stupidity...A FPU is added just for that, to not have to use the VFPU for simple fp calculations.
 
The UMD should have better access time and transfer rate compared to PlayStation 2's DVD and we would be streaming from the UMD often in games that want to maximize texture and geometry usage.

As far as texturing goes you could have a static texture buffer in VRAM and a dynamic texture buffer in VRAM.
Yeah, I'm thinking something like that would help the situation *a lot*. They could even stream music and textures simultaneously, I know that two streams method have been used even on PS1.

It would be best though, if they added just couple of more MBs of some cheap'o RAM that would be used for nothing but holding the EXE file in it, like you can do with that slow RAM on Gamecube. 4 extra MB of such RAM would probably be enough.
 
Paul, there is more to it than simple resolution...

As far as what you see on screen yes, IQ. Compare a 50" Projection vs a 20 inch, the 50 inch has the same resolution as the 20; however the pixels on the 50 inch are much bigger. This brings picture quality down.

But I was refering to Marco's post, I stated that:

PSP will not be outputting in 640X480 resolution, so you save memory and fillrate here already. Infact resolution is a fourth of what PS2 uses, so if you were to compare it directly, PSP has 8MB of vram.

My first part was right, however my second part was off. Purely stating PSP's resolution isn't 1/4th of what PS2 uses. However it is true that PSP will "get more use" in terms with it's memory do to several factors.
 
Not supporting dot3 would be silly, at least support it at half speed if nothing else (takes virtually no extra hardware at all).
 
marconelly!:
Play pretty much any better looking PS2 game that works with blaze VGA adapter, and there you go.
There's an issue of whether the game itself is optimized with native VGA support, and less than 10% of the PS2 library actually is. In the majority of cases, proscan out is hacked with varying results to image artifacting, screen positioning, color accuracy, and even the general functionality of just running properly (crashing, synchronization problems). Not being part of the general PS2 spec, the games aren't tuned to comply with and take advantage of the VGA display.

The Blaze's design is said to be a modification of the VGA cable from the PS2 Linux kit, so I wonder whether even the few games with native output are simply passed through like a true adapter should.
 
Is that only the peak for the VFPU ?

I thought it was. Its probably power or heat reduction scheme.

I am more curious about the GPU bit. I wonder how good it is.
 
Deadmeat said:
Panajev said:
Can the VFPU be used at the same time as the FPU or not ?
Probably not. R4000 is a single-issue scalar processor.
No standalone mode for VFPU combined with limiting FPUs to single issue would make scalar FPU pretty much completely useless.

Yet the slides very much claim two separate units (on separate cop pipes as well by the looks of it), when a single unit could be just as efficient and have the same functionality.
So I ask the question again - why waste silicon on redundant logic, and in a PDA chip, no less? :?

You have to remember that the design team behind PSP was more concerned with "architecture balancing"
So does architecture balancing include wasting silicon on things that neither add functionality nor increase speed?


Panajev said:
Unless they heavily modified the R4000i, which I would agree is extremely unlikely, the CPU core remains single issue and only able to push either the ALU or the FPU or the VFPU each cycle.
Not a problem with a not dumb compiler and attention paid by the coders when writing hand-assembly.
It's not a question of "problem" question is what's the use?
I can simply execute one scalar op on VFPU each other cycle and get exactly the same performance as you would using two FPUs.
 
Fafalada,

what if the VFPU could not execute scalar FP ops ?

Then the need of the separate FPU would be more apprarent: there could be savings that could be made in the design of the VFPU Control Logic and in the FPU Control Logic if that were the case.
 
Panajev said:
what if the VFPU could not execute scalar FP ops ?
Then it would be called SSE, not VFPU :p

Seriously though, taking away access to individual components (and possibly swizzling) from a Vector FP would drastically reduce its usability.

there could be savings that could be made in the design of the VFPU Control Logic and in the FPU Control Logic if that were the case.
Imo integrating the two into one should only save more though. (maybe one of resident engineer guys can give their input).
 
Fafalada said:
Panajev said:
what if the VFPU could not execute scalar FP ops ?
Then it would be called SSE, not VFPU :p

Seriously though, taking away access to individual components (and possibly swizzling) from a Vector FP would drastically reduce its usability.

there could be savings that could be made in the design of the VFPU Control Logic and in the FPU Control Logic if that were the case.
Imo integrating the two into one should only save more though. (maybe one of resident engineer guys can give their input).

You are right, integrating them could save even more logic at that point...
 
So we would be talking about 4 independent scalar FP ops or just a vector operation...
Je...I wasn't so wrong...

Judging by that they could use an APU as a VFPU. Considering it only will be rated at 333Mhz the heat produced shouldn't be an issue...
 
The Blaze's design is said to be a modification of the VGA cable from the PS2 Linux kit, so I wonder whether even the few games with native output are simply passed through like a true adapter should.
Yes they can. Pretty much all natively prog-scan enabled games work on it.

There's an issue of whether the game itself is optimized with native VGA support, and less than 10% of the PS2 library actually is. In the majority of cases, proscan out is hacked with varying results to image artifacting, screen positioning, color accuracy, and even the general functionality of just running properly (crashing, synchronization problems). Not being part of the general PS2 spec, the games aren't tuned to comply with and take advantage of the VGA display.
All I know is that most better looking games work with it with no, or some extremely small problems. VGA support is niche thing anyways, so working around small issues here and there is not a big deal. As for games that don't look that great to being with, well, who cares about VGA support on them anyways.

Besides, from what I've seen lately it's very rare that a game worth mentioning comes out and doesn't support pro-scan natively. Jak 2, SSX3, Prince of Persia, Beyond Good & Evil, Ratchet & Clank 2, Socom 2 all support it.
 
marconelly! said:
Besides, from what I've seen lately it's very rare that a game worth mentioning comes out and doesn't support pro-scan natively. Jak 2, SSX3, Prince of Persia, Beyond Good & Evil, Ratchet & Clank 2, Socom 2 all support it.



errrmmm.... not really... Jak2 and Socom2 are the only ones out of the ones u have mentioned...

R&C2, SSX3, do NOT. not natively, although they will probably work with the Blaze adapter...

not sure about POP and BGaE...
 
maybe not in Europe then, but I'm definitely playing SSX3 in pro-scan natively here in the US. Haven't gotten R&C2 yet, but the devs stated it supports pro-scan in interviews and I've seen it confirmed at a few forums.
 
kaching said:
maybe not in Europe then, but I'm definitely playing SSX3 in pro-scan natively here in the US. Haven't gotten R&C2 yet, but the devs stated it supports pro-scan in interviews and I've seen it confirmed at a few forums.


oh, sure... should have known... still, that means it will work with the Blaze adapter flawlessly. very good news. shame i'm broke so i'll have to start renting... *shivers*... :D
 
london-boy, they actually all do in their NTSC releases (OK, I haven't seen the option with my own eyes in R&C 2 but devs said it'll be there)

The weird thing is, SSX3 doesn't even mention how to enable prog-scan in the manual. You are supposed to press and hold X and Triangle, I think during the bootup, and you get the option to enable it.
 
marconelly! said:
london-boy, they actually all do in their NTSC releases (OK, I haven't seen the option with my own eyes in R&C 2 but devs said it'll be there)

The weird thing is, SSX3 doesn't even mention how to enable prog-scan in the manual. You are supposed to press and hold X and Triangle, I think during the bootup, and you get the option to enable it.


guess i'll give SSX3 a try...
 
Marc said:
The weird thing is, SSX3 doesn't even mention how to enable prog-scan in the manual. You are supposed to press and hold X and Triangle, I think during the bootup, and you get the option to enable it.
Thanks Marc, I didn't know about this either :) and it does indeed work.

V3 said:
My guess is to reduce heat build up in that VPU.
:? Why don't they just increase the area of the chip x10, that should also greatly improve heat dissipation :/

ShinHoshi said:
So we would be talking about 4 independent scalar FP ops or just a vector operation... Je...I wasn't so wrong...
I think you misunderstood me, I was still talking about a vector operation in both cases. But the "good" vector ISAs give you nice access to vector scalar values and possibly also mixing them from one operand to another.
This doesn't mean that you can execute arbitrary operation on each vector component simultaneously though - you still use vector instructions.

Anyway, it'd be great if VFPU was as functional as an APU but I'm not gonna hold my breat for that. Though I wonder whether it would be more expensive then having dual issue for FPUs instead.
 
Back
Top