Let's talk... PSP graphics + Design

[chaphack]

What was PSP max polygons again? 12m?

32M.
Which I suppose strongly supports theories it will draw <500k per second you are predicting eh? :?
Speaking of which, why reduce PSP to PSOne levels only? Why not predict it will draw "somemore" then GBA only, I people already keep saying GBA is PSOne level graphics anyway.

Anyway to add my stupid 2cents to the banter of this thread
The thing is basically rated 1/2PS2 drawing-rate, with a screen that's 1/4 the size. In other words, it's potentially faster.
Memory will be the big limit yes, but nonetheless, the first and most obvious target here would be PS2 ports.

But I'll let you know if I changed my mind about it when/if I get to see the devkit specs.

hohoho! so the number stands at 32m. STILL, bleemcast++ polys particles sound about right. I no be seeing high DC quality textures with the limited RAM. bleemcast do have some nice filtering, will PSP goodie filtering?

PSOne level is mainly for the power saving feature. So what do you think about my thought on power saving via variable graphics?

Lastly, Fafracer 2k5-Portable, WLAN head to head and PS2 connectivity?!!!???

 

[Panajev2001a]

bleemcast++ polys particles sound about right

Excuse my french, but WTF do you mean by that ?

Xbox is Bleemcast++ polys particles...

Xbox 2 will be Bleemcast++ polys particles...

And so on...

For pure per-frame texturing, Dreamcast has 8 MB of VRAM ( no streaming per frame sir ): there we have to fit complete display lists, all the textures used in the scene, the frame-buffer and the back-buffer.

Easily, for all your scene textures you would probably have like 3.5-4 MB free.

PSP's GPU should still be able to stream textures from main RAM and considering its resolution, 2 MB of VRAM are not bad ( compared to PlayStation 2 ).

Remember this resolution is 1/4th of what Dreamcast and PlayStation 2 use: it is like having 4x VRAM --> this would make, in a 640x480 world, the PSP's GPU have 8 MB of VRAM.

PSP needs less main RAM to store polygons for those games which will use the HW tessellation unit for HOS ( a big saving in memory footprint for vertex data ) and thus would have still a good amount of space to buffer textures for the GPU ( to stream them for example ).


Dreamcast has 16 MB of main RAM vs 8 of the PSP: as I said, using HOS and other main RAM saving techniques, they should be able to have better than Dreamcast Texturing qithout too many issues.

 

[zurich]

Don't forget that the PSP target screen resolution will be quite a bit smaller too.

 

[ShinHoshi]

PSP's GPU should still be able to stream textures from main RAM and considering its resolution, 2 MB of VRAM are not bad ( compared to PlayStation 2 ).

Exactly my thoughts. Why are you so worried about VRAM ???? Remember how PS2 works and apply the same philosophy to PSP. With such an efficient fillrate and a fast bus you can update very fast these 2MB allowing you a high level of freedom in what textures concerns.

 

[chaphack]

You da man Pana.
BUT lets wait and see. Sony has, like pretty PR specs sheets and well, pretty. We shall wait and see. Though lets all pray to the gods that IQ be tons better this time round.

 

[maskrider]

You da man Pana.
BUT lets wait and see. Sony has, like pretty PR specs sheets and well, pretty. We shall wait and see. Though lets all pray to the gods that IQ be tons better this time round.

IQ ? I am not very sure (other than super AA), I will be able to see significant difference in IQ when there are enough polygons to fill the pretty small screen (if it is smaller than UX50, as I have seen the UX50 and think that the screen is rather small).

 

[hey69]

am I the only one here that thinks that 4.5inch widescreen is quite big?

i think I get to used on my GBAsp last days

 

[ChryZ]

I have seen the UX50 and think that the screen is rather small).

UX50's Dimensions are (W x D x H) 4.1 in x 3.5 in x 0.7 in ... so it's screen is indeed smaller. PSP's screen will be as wide as the whole UX50 (^_^

 

[hey69]

so basicly it will be the size of a psONE ..
hey , hmm, i cant force that in my pocket of my vest !

 

[ChryZ]

so basicly it will be the size of a psONE ..
hey , hmm, i cant force that in my pocket of my vest !

PSone's Dimensions are 193 millimeters (7.6 inches W) by 38 millimeters (1.5 inches H) by 144 millimeters (5.7 inches D) ... I am sure the PSP will be smaller than that.

 

[notAFanB]

BUT lets wait and see. Sony has, like pretty PR specs sheets and well, pretty. We shall wait and see.

well obviousely.

Though lets all pray to the gods that IQ be tons better this time round.

don't hold your breath, at this screen size (and resolution) I wouldn't expect uber levels of AA (if any at all) since that would be rather blurry.

Remember this resolution is 1/4th of what Dreamcast and PlayStation 2 use: it is like having 4x VRAM --> this would make, in a 640x480 world, the PSP's GPU have 8 MB of VRAM.

while you can scale the frame buffer requirements linearly like that how does that work for texturing?

 

[Panajev2001a]

Front-buffer is 1/4th, Back-buffer is one fourth, Z-buffer is one fourth.

So we can scale by dividing by 4 the non texture related portion of VRAM ( Maybe I exagerated multiplying by 4 the VRAM, but let's keep work this out ).

On the GS you would "normally" leave ~1.5 MB for textures ( part used for streaming buffer and part as static texture bufffer ).

2.5 MB would be taken by Frame-buffers and Z-buffer: 2.5 / 4 = 0.625 MB.

2 - 0.625 = 1.375 MB

That is like 68.75% of VRAM.

PSP's GPU also seems to have better than GS's texture compression ( enough to deserve its own space in the specs announcement ) and that should help leverage the Texture space.

The pipe that connects the GS and the GIF ( GIF-to-GS bus ) reaches 1.2 GB/s peak: the PSP's GPU is on a ( shared ) 2.6 GB/s one.

There is a good chance we will get to stream more textures per frame than we did before: the pipe is larger, there is less vertex data floating around ( more use of HOS, no re-sending, hopefully, geometry for multi-pass rendering, texture compression, etc... ) and System RAM's latency is lower than what even RAMBUS Direct DRAM with on-die memory controller offered ( it's e-DRAM after-all ).

Also with 1/4th of the resolution we likely need less texture resolution to convey a similar level of detail without pixellization or shimmering ( which higher resolution texture helps and mip-mapping and texture filtering have to come to the resque ):

512x256 texture maps now are MORE than enough to have textures mapped on polygons which take the whole screen ( imagine a HUGE rectangle facing the screen and its normal being anti-parallel to the view vector ). This polygon will take at the most 480x272 pixels and in this case we would have MINOR pixellization ( we have bi-linear filtering for shimmering and pixellization anyways ): the Pixels:Texels ratio is only ( and we have to take into account that we have a vertical stretching of the texture to cover this polygon as raw math would tell us we have more texels than pixels ) 1:1.0625.

With a 256x256 map the Pixels:Texels ratio would be approximately 1:2 and that will result in minor blurring.

The Pixels:Texel ratio for a 640x480 screen resolution and a 256x256 map ( displayed in similar conditions ) would be 1:4.6875 or almost 1:5.

 

[notAFanB]

thanks that makes more sense now. although they should really go for trilienar+ texture filtering since I still want the usage of my eyes

 

[Panajev2001a]

I'd prefer either bi-linear + mip-mapping or even more anisotropic bi-linear + mip-mapping.

Tri-linear blurs even the highest mip-map level ( full-resolution ) as it blends two samples, each produced by bi-linear filtering, taken respectively from the current mip-map level and the next mip-map level.

In proper english:

1) for tri-linear filtering we take 4 neighbouring texels from the current mip-map level and other 4 neighbouring texels from the next mip-map level,.

2) after that we bi-linear filter each group of texels.

3) then we blend the two results/sub-samples together.

 

[Paul]

So Pana, what are your in-game-graphics estimations for PSP? Would you say ZOE(not ZOE2) would be possible on PSP?

I wouldn't say RRV type graphics are out of the realms of possibility.

 

[zurich]

Hmm, since it is an LCD, I'm guessing the PSP will output progressively by default? No half frame tricks?

 

[Megadrive1988]

I would just be pleased with Ridge Racer 1&2 or Rave Racer
arcade graphics (though at lower res) which are alot nicer than PS1's RR1, RRR, Rage Racer, RR Type 4 graphics.

 

[PC-Engine]

Easily, for all your scene textures you would probably have like 3.5-4 MB free.

...and you conveniently forgot about PowerVR's 8:1 VQTC...

BTW for those of you arguing about the screen size, just know that it's smaller than a 4:3 aspect ratio 4.5" LCD so it's pretty small

 

[Panajev2001a]

Easily, for all your scene textures you would probably have like 3.5-4 MB free.

...and you conveniently forgot about PowerVR's 8:1 VQTC...

BTW for those of you arguing about the screen size, just know that it's smaller than a 4:3 aspect ratio 4.5" LCD so it's pretty small

And you are forgetting about 8 bits CLUT 4:1 ( and the fact that the Dreamcast cannot swap the textures while rendering the frame )

 

[Fafalada]

while you can scale the frame buffer requirements linearly like that how does that work for texturing?

Not that I really disagree with Pana's explanation but I think it can be put a bit more simple then that.
First and foremost, the screen is actually physically smaller then 1/4 the size of an average TV - eg. pixels will be quite small and perceived detail will be that much higher - try playing PSOne on that LCD if you haven't yet to observe the effect (this also relates to the talk of uber AA and filtering and what not).
Second, the issue of pixel resolution - typical objective of on screen texturing is to get average 1:1 pixel/texel ratio. Smaller pixel resolution - less texels needed to get the ratio, it's fairly simple math.

In short you have much smaller texture requirement then DC to get equivalent detail. Personally I'm more wondering about executable sizes myself, if you directly ported a PS2 game over it'd take nearly half of main memory with that alone.

PSOne level is mainly for the power saving feature. So what do you think about my thought on power saving via variable graphics?

There's not enough known about GPU to argue that. Only CPUs 'clearly' show scalable power requirements, and by the looks of things the second R4k will be 90% idle in games, so there's power saving right there.

...and you conveniently forgot about PowerVR's 8:1 VQTC...

The PSP GPU includes TC also in case you missed it (though we don't know what kind yet).