-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
PSP is inded faster than PlayStation 2 (AGC update)
- Thread starter Panajev2001a
- Start date
God's Hand
Banned
It's faster at one thing that won't matter on a tiny screen. Okay...
Panajev2001a
GAF's Pleasant Genius
God's Hand said:
You think that texture shimmering would not be a bad problem especially for small screens ?!?
I think it would.
The smaller the screen is, the more we have to work on good resolution for the screen (480x270 means quite small pixels) and good Image Quality (edge and texture aliasing are even worse offenders than on PlayStation 2 if left unchecked and if we do not use mip-mapping).
When things are small, they ought to look sharp and detailed, not messy and aliased.
Lord Error
Insane For Sony
This is very good news. Not only the speed part, but the awareness they have of impotance of good filtering on a sharp LCD screen. Trilinear filtering requires mip-mapping, btw. which is confirmed to have (a lot) better implementation than it does on PS2. Thre's almost no doubt now that the games will look better and cleaner than the majority of PS2 games. There's very few games on PS2 that even use trilinear.
Panajev2001a
GAF's Pleasant Genius
Phoenix said:
Well, there are always Memory Stick modules: recently they iontroduced Memory Stick Pro High Speed at 2 GB and Memory Stick Pro Duo High Speed at 1 GB, so the price on 512 MB Memory Stick Pro Duo should drop even further.
The PSP might be faster on a theoretical level, and it may have some advantages with some display effects, but most of the games (and even a lot of the demoes) so far haven't been PlayStation 2-par. Sure, the games will definitely look better as developers gain more experience with the hardware, but really -- I'd be somewhat disappointed in PSP if it were a console . What really makes it impressive is the fact that it's almost as powerful as PlayStation 2 and is portable.
I agree. The PSP can generate some nice-looking visuals, but just about everything I've seen is not quite PS2-level (or maybe first-generation PS2 at the best).snapty00 said:
Incidentally, I think the latest shots of DS games showcase graphical abilities beyond what the N64 could do, or at least up to par with the system's last tier of games.
TekunoRobby
Tag of Excellence
A bit worried with the deluge of accessories for the system at launch, maybe Sony plans on really pushing this machine as a do-it-all device. The keyboard especially suprises me. Of course it could be a psychological ploy for the mainstream to show it's not just a great device for games and possibly pick up a few sales from the older CE-driven audience.
Tri-linear filtering is a very good thing.
Tri-linear filtering is a very good thing.
The Faceless Master
Member
seriously, do you really think they would let homebrew code run off a memory stick?Panajev2001a said:
i mean, i can see someone maybe finding a way to force or trick the issue, but i don't see sony letting it happen on purpose
Panajev2001a
GAF's Pleasant Genius
human5892 said:
It might very well be a combination of early RAM specs which had only 8 MB of main RAM (the PSP now has 4x the amount of main RAM, that is 32 MB) and developers being cautious about battery life thus keeping performance down a bit.
TekunoRobby
Tag of Excellence
For first party peripherals at launch, I would think so. More specifically having three different accesories available at launch that expand upon the basic capabilities of the PSP to that degree is quite a lot (not in a bad way but a suprising way). Of course in the long run 3 isn't a deluge.kaching said:
Doom_Bringer
Banned
BATTERY LIFE!!!!
Chittagong
Gold Member
exactly. There was figures + speculation from some website in OA, surprised to see nothing here.Doom_Bringer said:
Panajev2001a
GAF's Pleasant Genius
I could not find more info on that subject.
Anyways, even if tri-linear took two cycles, even though they said the GPU would not have a speed penalty for switching from bi-linear to tri-linear (even though it will use more bandwidth which might slow down other things, depending on the cases)... that would still be 332 MPixels/s with tri-linear which taking into account the difference in screen resolution would be worth ~730 MPixels/s with tri-linear on PlayStation 2(which does not manage more than 600 MPixels/s with tri-linear).
Tri-linear filtering might be faster or quite a lot faster than on PlayStation 2 which is a good thing IMHO.
Anyways, even if tri-linear took two cycles, even though they said the GPU would not have a speed penalty for switching from bi-linear to tri-linear (even though it will use more bandwidth which might slow down other things, depending on the cases)... that would still be 332 MPixels/s with tri-linear which taking into account the difference in screen resolution would be worth ~730 MPixels/s with tri-linear on PlayStation 2(which does not manage more than 600 MPixels/s with tri-linear).
Tri-linear filtering might be faster or quite a lot faster than on PlayStation 2 which is a good thing IMHO.
There's still question of texture cache and how it affects the rendering performance whether it's bilinear or trilinear. Trilinear is pretty useable on PS2 IF you can fit the texture in a single texture page, which isn't exactly easy in most of the games.
I certainly hope the hardware clipper has improved but it's most likely still half assed...
I certainly hope the hardware clipper has improved but it's most likely still half assed...
Panajev2001a
GAF's Pleasant Genius
RuGalz said:
You have 8 KB and for tri-linear and this means you are forced to use the extra space for mip-mapping.
I was not aware that tri-linear took a single cycle on the GS, even if the texture fit in the cache (does the cache has the output bandwidth to push 8x32 bits texels to the texture filtering logic ?).
Sure, if you break the page, even with bi-linear you add an extra cycle as that is what it takes for the cache/buffer to be filled again.
I do suspect that they worked on the texture cache of the PSP GPU: it seems that they focused on several key areas of PlayStation 2 bottlenecks and tried to improove upon them.
I think the cache should allow single-cycle tri-linear and in the cases in which S3TC would behave better than CLUT we have more chances not to break out of the cache.
I certainly hope the hardware clipper has improved but it's most likely still half assed...[/QUOTE]
It cannot be half-assed compared to PlayStation 2 as PlayStation 2 has none
.No trilinear isn't free on PS2 even if all textures are on the same texture page. I was merely pointing out that even if trilinear on PSP is free texture cache breakage still would be a problem. It might not be such big deal with smaller screen size hence textures are usually smaller in most of the cases. But there are certainly times when able to use large texture makes it convenient.
The clipper... Since you still have to do work on it, handling the additional case hardware is providing is rather simple... It's pretty silly. But maybe they dump the extra sillicon for S3TC...
The clipper... Since you still have to do work on it, handling the additional case hardware is providing is rather simple... It's pretty silly. But maybe they dump the extra sillicon for S3TC...
doncale said:
Are you certain of that? Model 3 games did not appear to use mipmapping at all. I know for a fact that two of the DC Model 3 ports were lacking mipmapping (VF3 and VOOT), so I'd imagine the originals were as well. I also don't recall seeing any mipmapping in any Model 3 title.
It has been a long time, however...
inpHilltr8r
Member
He's probably talking about the guard band.Panajev2001a said:It cannot be half-assed compared to PlayStation 2 as PlayStation 2 has none
Lord Error
Insane For Sony
Haha, yeah right. How did you arrive to that brilliant conclusion?
Rugalz, do you have some, hmmmm, solid data about this
or are you basing this quote on the some of the older info (which sounded inconclusive) and Beyond 3D speculation about it.Panajev2001a
GAF's Pleasant Genius
Argyle said:Doesn't the VU have a CLIP instruction or something?
(I know, I know, the rest of your clipping code doesn't write itself...
I heard it is lovely when you are doing multi-texturing too <insert random ps2 programmer imprecating and roaring>.
Panajev2001a
GAF's Pleasant Genius
COCKLES said:
On the contrary: graphics must be clean and sharp.
Panajev2001a
GAF's Pleasant Genius
RuGalz said:Marconelly: Ya it's not based off the speculation at B3D.
And actually PSP does have smarter texture cache scheme.
But why does clipper have to be half assed...
So, it still only clips the front-clip plane only (as in the last GDC talk in San Jose), right ? (but... but... we have a big guard band.... IT IS THE SAME AS ON PS2 and IT WAS NOT ENOUGH).
That is a pain in the ass, you have to do object-space clipping before sending stuff to the GPU T&L unit.
Panajev2001a
GAF's Pleasant Genius
RuGalz, you are complaining about the clipper, but here I check and some people (HEY meee ) still working in the salt mines (read PlayStation 2), while you have a platform with:
1.) fairly abstracted DMA Controller (although I'd like to qadapt my DMA class... it is so cute... I still have the pictures when it took it first steps and called me "dadda"... uh-oh, getting to close to my code again) with Display List culling.
2.) Hardwired T&L (no micro-code to write and to manage: just writing it is fun... double buffering VUs outputs and inputs too, but adding to that micro-code upload starts to annoy me some).
3.) Hardware managed multi-texturing (whether single or multi-pass I do not care at this point, but it would matter to peoiple doing custom T&L on the VFPU): I do not think you have to play with GIF registers and rendering contexts by hand.
4.) Hardware supported stencil-buffer.
5.) proper GPU Mip-mapping LOD calculations.
6.) CLUT and S3TC.
7.) single VFPU design sitting on co-op pipe (no VIF).
8.) 33 MHz more on the CPU.
9.) lower latency main RAM (using mobile DDR with embedded memory controller they should manage that, I'd think).
10.) more blending modes (I think you do have more blending modes than the GS).
11.) support for all Z-buffer tests: Equal, Never, Less than and Greater than (the GS decided that they did not needed all of them [why should we have Less Than ?]: of course that creates a pain for doing Carmack's reverse, but I am not doing stnecil shadows now, so the pain is not mine yet...)
) still working in the salt mines (read PlayStation 2), while you have a platform with:1.) fairly abstracted DMA Controller (although I'd like to qadapt my DMA class... it is so cute... I still have the pictures when it took it first steps and called me "dadda"... uh-oh, getting to close to my code again
) with Display List culling. 2.) Hardwired T&L (no micro-code to write and to manage: just writing it is fun... double buffering VUs outputs and inputs too, but adding to that micro-code upload starts to annoy me some
).3.) Hardware managed multi-texturing (whether single or multi-pass I do not care at this point, but it would matter to peoiple doing custom T&L on the VFPU): I do not think you have to play with GIF registers and rendering contexts by hand
.4.) Hardware supported stencil-buffer.
5.) proper GPU Mip-mapping LOD calculations.
6.) CLUT and S3TC.
7.) single VFPU design sitting on co-op pipe (no VIF).
8.) 33 MHz more on the CPU.
9.) lower latency main RAM (using mobile DDR with embedded memory controller they should manage that, I'd think).
10.) more blending modes (I think you do have more blending modes than the GS).
11.) support for all Z-buffer tests: Equal, Never, Less than and Greater than (the GS decided that they did not needed all of them [why should we have Less Than ?]: of course that creates a pain for doing Carmack's reverse, but I am not doing stnecil shadows now, so the pain is not mine yet...
)Lord Error
Insane For Sony
Ah, I see. Well, if what has been said in that specualtion, based on the SCEA presentation, is true, then yes, that's pretty half assed solution. I just hope VFPU or CPU is fast enough to handle proper clipping without significant performance hit.Marconelly: Ya it's not based off the speculation at B3D.
Panajev2001a
GAF's Pleasant Genius
RuGalz said:Pana: Sure, there's a ton of things PSP does that's far more elegant. But they went so far with everything why not finish the job.
Yes, but without fractional LOD and the ability of using different LODs on different patches without cracks is it really that useful to you ?
Panajev2001a
GAF's Pleasant Genius
RuGalz said:
Problems with scissoring ??? I thought clipping was the major thing.
About the patch thing, well if you had fractional LOD and no cracks even if neighbouring patches had different LODs, I personally would use it all the time.
That would provide great dynamic geometry LOD.
Drinky Crow
Banned
Technically, the N64 has support for trilinear filtering. It was never used, though.
Can I just ask a really noob question? Why do you even need clipping at the sides of the screen?
I can understand front, and to a certain extent far plain clipping, to avoid ugly degenerate polys "sticking trough" the viewpoint. But isn't view frustum clipping and scissoring only there to avoid spending fillrate/setup on invisible polys?
With polygons becoming smaller (and therefore "easy" to just cull), and fillrate being quite high - even on PSP - wouldn't it be possible to halt the drawing of polys in the current strip or fan, when it crosses the screen boundary?
I can understand front, and to a certain extent far plain clipping, to avoid ugly degenerate polys "sticking trough" the viewpoint. But isn't view frustum clipping and scissoring only there to avoid spending fillrate/setup on invisible polys?
With polygons becoming smaller (and therefore "easy" to just cull), and fillrate being quite high - even on PSP - wouldn't it be possible to halt the drawing of polys in the current strip or fan, when it crosses the screen boundary?
Not sure if this useful - something from the CEDEC conference a few days ago in Japan.
http://www.4gamer.net/news/history/2004.09/20040909185715detail.html
There's a video collection at the bottom of the article that shows the demos in action that are discussed in the text.
http://www.4gamer.net/news/history/2004.09/20040909185715detail.html
There's a video collection at the bottom of the article that shows the demos in action that are discussed in the text.
I could say the same for most 3d features on new handheld chips, and that doesn't stop respective makers from hyping them to deathCockles said:
What you're talking about is the eDram bandwith (what page buffers output). To my knowledge there is another layer of texel cache(much smaller then 8K) - which gives you stuff like 32bit bilinear for free.Panajev said:
Actually it Can. When I write a clipper on PS2 it's at least in the Right place of the pipeline for one. And frankly, the one real complaint I have about writting my own clipper is that GS doesn't accept H-space coordinates, so my shader pipeline is less straightforward than it could be.It cannot be half-assed compared to PlayStation 2 as PlayStation 2 has none
Still orders of magnitude better then doing object space clipping or any similar horror though.
Ok, enlighten me, how is that a good(or better) thing in a single issue (CPU&FPU) design? Mind you I'm not dissing VFPU (it's my favourite part of the machine so far), but you seem to be making the assumption here, so let's hear it.
That's kinda the point no? If you are correct, it's also a half assed feature that doesn't make much sense to use. Why would anyone want that, over a full implementation of the most basic functions, is beyond me.
That's what pixel scissoring does (and pretty much all chips support it). However, the rasterizer has limitations of its internal viewport (guardbands) which in case of PSP are 0-4096 pixels wide/tall.Squeak said:
If polygon crosses those borders, attempting to draw it causes visual anomalies (on most hardware that had this issue, it looks ike random crap splodging over the screen).
Panajev2001a
GAF's Pleasant Genius
Squeak said:
Because of this:
Panajev2001a
GAF's Pleasant Genius
I am not saying this is better than CPU + FPU, besides the PSP CPU has both the FPU and the VFPU
.What I am saying is that the VFPU sitting on the co-op pipe is easier to use than VIF + VU in micro-mode.
Also, VU0 in macro-mode basically pushed you to a single issue design already.
My preference would be a dual issue core that allowed you to pair integer instructions with either scalar FP or Vector FP instructions: basically both VFPU and FPU would be co-processors (they might even share resources to save space) and you could issue only to one of the two each cycle, an acceptable compromise.