PSP question
- Thread starter passerby
- Start date
chaphack said:
Try covering the Sony logo at the front....
it's both, less of an since since Tekken titles have always been rather the dark side.
I do. well actually mostly to boot up the kof titles now and then.
could you be a little less vague. PS <8bit clut has a lot of trouble with large color variations (potraits, cloths marks, see lei fangs chineses dress).
for material surfaces it would be fine but the sub 256*256 mapping resolutions really hurt it.
too late 8)
notAFanB said:
yeah, the fact that the easy VGA connectability of DC wasn't used on later caonsoles really bugged me this generation.
still, this does not mean that DC has superior IQ to PS2, just more consistant. PS2 has "some" games with IQ and textures that blow DC games out of the water, but it also has many lazyjobs with undecent output. but hey all consoles have embarrassments, PS2 just happens to have more than the competition for the simple fact that it's the market leader and software houses are prepared to release pure crap for it just to make a quick buck...
DeadmeatGA
Banned
...
On the other hand, I can't say the same about CELL.......
Probably not. R4000 is a single-issue scalar processor.
It is very likely that FPU and VFPU have their own sets of registers. Other than that, the Integer Unit + FPU + VFPU of PSP forms single processor, just like how X86+X87+MMX+SSE forms the single processor in the PC world.
You have to remember that the design team behind PSP was more concerned with "architecture balancing" than extracting the maximum performance possible from sillicon. I can actually see that the designers have put a considerable amount of efforts to balance the PSP architecture and I appreciate that. I have no real criticism of PSP architecture other than the obvious memory shortage.(Why not use some cheapo external DDR DRAM)
On the other hand, I can't say the same about CELL.......
Re: ...
[sarcasm ON]
REALLY
We must have missed that! Why don't you create another 84 new topics (which will be locked in the following 12 hours, depending on mods availability) on how Sony will fail miserably, on how Cell will do less than current generation of hardware... just to keep us updated.... we wouldn't wanna forget how you feel about Cell...
[sarcasm OFF]
DeadmeatGA said:
[sarcasm ON]
REALLY
We must have missed that! Why don't you create another 84 new topics (which will be locked in the following 12 hours, depending on mods availability) on how Sony will fail miserably, on how Cell will do less than current generation of hardware... just to keep us updated.... we wouldn't wanna forget how you feel about Cell...
[sarcasm OFF]
marconelly!
Veteran
Well, play them. JAk 2 has strikingly better textures than R&C or R&C2, that's not even worth comparing.
Much better image quality (no shimmer) and beter textures than Shenmue, while running at 2x framerate. I compare both games simply because they have simillar room-loading structure and realistic look.[/quote]
Your funny.
PSP has over 30 times the memory ammount of the SP, and I didn't even go into bandwidth numbers yet. And your saying PSP has a lack of memory? How pathetic has your trolling become.
There is no memory shortage for PSP, it does not exist.
The VRAM is only 2mb sure, but you don't look at the full picture. 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.
Main DRAM, 8MB. However the hardware tessellation unit using HOS will be able to compress vertex data.
Panajev2001a
Veteran
DeadmeatGA said:
You are correct and I did not check that fact before asking the question.
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.
Likely, but until we can understand how exactly the 2.6 GFLOPS number comes out from the 333 MHz CPU then we cannot exclude something like a customized MIPS3D ASE is being used.
After all, SCE mentioned that the CPU was using custom CG extensions to its ISA.
Let's keep CELL out of this discussion, ok ?
You got correct your analysis of PSP's chipset: a brand new chipset built with 90 nm technology targeted for GCN like performance ( if you exclude the difference in main RAM... Flipper does not support Hardware HOS tessellation while PSP's GPU does so it is far more likely that good and experienced developers will make use of HOS for more and more objects thus saving more main RAM [I assume both GPUs can use different instances of the same model with slightly different textures and so on to reduce the amount of space geometry data takes in main RAM] ).
Of course I do not expect more than DOT3 blending on PSP's GPU ( thus "qualifying" for pixel shading under a bit loose definition of the term [add dependent texture reads and I will not complain about what you call it
] ) while GCN has its nice TEV unit for Pixel Shading and Multi-texturing.The reason for DOT3 blending would be again to balance the architecture better by offering another way to save main RAM ( yes I know the Dreamcast could have used it too and so can the GCN
, but the PlayStation 2 cannot and for developers with PlayStation 2 background this would be a welcomed addition ) thanks to the use of Normal Mapping or the patented POLYBUMP technology: basically what DOOM III does.This is the same thing PVR MBX does and they have shown it running with POLYBUMP samples: it allows to reduce main-RAM usage and it allows to speed up GPU processing as it can help reduce the load to the Dynamic Tessellation unit in the GPU.
Some ps2 games may have better textures and more polygons than dreamcast games(well, many ps2 games do), however, I doubt even one can match the visual clarity provided by dreamcast's vga out. Heck, I'd be surprised to find a gamecube or xbox game that provided as much clarity.(unless it's an xbox game that supports above 480p)
marconelly!
Veteran
Not really...
640x448 = 286720
480x272 = 130560
that's about 2.1x less than PS2
However, I think 2MB VRAM is just fine for all the buffers and texture scratchpad on PSP. At 24bit color depth you need ~1.5MB for front+back+Z buffers, so the remaining 0.5 can be used for constant texture upload, like PS2 is doing. Hoewever, considering that you have to keep all the executable code, models and textures in that 8MB of RAM, I think things might become less than desireable. GBA comparision doesn't work for two reasons - a) it's cartridge is effectively being used as a memory, b) it's games are much simpler than what everyone is expecting from PSP. I think this gen cosole games have executables that range from 2-4MB, and that is a lot when you have to put all the textures and models there too (sounds I guess can go to that 2MB in the media engine?)
Play pretty much any better looking PS2 game that works with blaze VGA adapter, and there you go.
Bleh, I still doubt, it may be vga but I....oh wait, ps2 does support native vga out, doesn't it? Well, so does gamecube(I think...or does the cable have a chip that converts the signal to vga?) and its quality often isn't on par with dreamcast, and at best probably still slightly below.(though that may be some form of antialiasing blurring it a little)
Panajev2001a
Veteran
8 FP ops/cycle would be 2.6+ GFLOPS at ~333 MHz
2.6 GFLOPS is the number that SCE presented.
Is that only the peak for the VFPU ?
Does that count the VFPU and the FPU ?
In the first case it would make the most sense as if the VFPU were a normal 128 bits SIMD FPU it would have a peak of 8 FP ops/cycle ( FP MADD ).
The second case would make less sense as if we go by the assumption that the R4000i used in the PSP is still a single-issue core then there is just no way both the VFPU and the FPU can be issued MADDs every cycle.
Well, we could think that 8 FP ops for the VFPU and 2 FP ops for the FPU are every other cycle ( in such a way that the two would not over-lap ).
This would deliver only 1.6 GFLOPS.
I think we can exclude that the quoted 2.6 GFLOPS is a benchmarked number and more of a theoretical peak.
We would have to do 16 FP ops every other clock cycle to reach the peak value we are looking for.
I think that the 2.6 GFLOPS figure is the peak of the VFPU and it does not take into account the use of the FPU as it cannot be used to increase the peak FP processing value.
2.6 GFLOPS is the number that SCE presented.
Is that only the peak for the VFPU ?
Does that count the VFPU and the FPU ?
In the first case it would make the most sense as if the VFPU were a normal 128 bits SIMD FPU it would have a peak of 8 FP ops/cycle ( FP MADD ).
The second case would make less sense as if we go by the assumption that the R4000i used in the PSP is still a single-issue core then there is just no way both the VFPU and the FPU can be issued MADDs every cycle.
Well, we could think that 8 FP ops for the VFPU and 2 FP ops for the FPU are every other cycle ( in such a way that the two would not over-lap ).
This would deliver only 1.6 GFLOPS.
I think we can exclude that the quoted 2.6 GFLOPS is a benchmarked number and more of a theoretical peak.
We would have to do 16 FP ops every other clock cycle to reach the peak value we are looking for.
I think that the 2.6 GFLOPS figure is the peak of the VFPU and it does not take into account the use of the FPU as it cannot be used to increase the peak FP processing value.
Panajev2001a
Veteran
marconelly! said:
You also do not need as high resolution textures as PlayStation 2 to retain the same texturing quality: lower resolution helps to keep the texel to pixel ratio in balance.
A 512x512 texture would be great for PlayStation 2, but for PSP's 480x272 screen resolution it is even a bit big if you know what I mean.
Several models and some background parts can be modelled using HOS and this would save main RAM and main RAM-to-GPU bandwidth leaving more for texture streaming.
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.
In main RAM you would replicate that, but in bigger scale ( we have more memory ): a static and a dynamic texture buffer ( from the static texture buffer we would keep the textures that are used more than once in the current and following frames and the dynamic texture buffer would be used to stream textures in and out the UMD.
You are correct, I think I/O code/ Networking code and Audio data will go in the Media Engine's 2 MB e-DRAM memory pool.
Panajev2001a
Veteran
ShinHoshi said:
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.
Panajev2001a
Veteran
Paul, there is more to it than simple resolution...
You are playing at 480x272 on a 4.5'' display and the pixel size is likely to be quite smaller than the pixel size of a 640x448 picture on a normal monitor/CTR screen people use with their PlayStation 2.
Smaller pixel size improoves the Image Quality quite a bit ( reduces edge aliasing effects as it becomes more difficult to notice the stair-case step effect ).
You are playing at 480x272 on a 4.5'' display and the pixel size is likely to be quite smaller than the pixel size of a 640x448 picture on a normal monitor/CTR screen people use with their PlayStation 2.
Smaller pixel size improoves the Image Quality quite a bit ( reduces edge aliasing effects as it becomes more difficult to notice the stair-case step effect ).
Similar threads
- Deleted member 13524
- Gaming Technology
