doncale said:
interesting update Panajev. we know that PS2's GS has approx 48 GB/sec bandwidth, which it needs to feed 16 pixel engines/pipelines. PSP only has 4 pipelines to feed so 10.4 GB/sec seems pretty decent.
10.4 * 4 = 41.6 GB/s
Very close in terms of bandwidth: I suspect that more bandwidth is being pulled from the Texture Units than the Pixel Engines.
GS' e-DRAM had two busses that connected the Pixel Engines to the frame-buffer area and one smaller bus for texture data.
Each DRAM macro on the GS had basically three busses.
PlayStation 2's GS: 2,560 = 16 * 64 (from FB) + 16 * 64 (to FB) + 16 * 32 (from TB)
PSP's GPU: 512 bits.
http://www.extremetech.com/slideshow_viewer/0,2393,l=&s=201&a=133950&po=9,00.asp
If this is the same DRAM macro we have 2 of these in the GPU and 2 of these for the Media Engine with the difference that the Media Engine e-DRAM would use a 128 bits interface for the two banks in the DRAM macro and the GPU is using a 128 bits interface for each bank.
128 bits * 2 banks * 2 DRAM macros = 512 bits.
Pretty nice that they went and modified that part of the specs.
I think they did not have enough bandwidth for bi-linear filtering to be done in a single cycle and they faced with the option of 322 MPixels/s of fill-rate with bi-linear filtering on or havign to majorly re-work the Rendering core to add the opportune resources (read: bigger texture cache) to allow bi-linear texture filtering to be done in a single cycle.
Before:
32 bits RGBA (PSP can do 32 bits rendering) + 32 bits Z (or 24 bits Z + 8 bits Stencil) = 64 bits per Pixel Engine.
64 * 4 = 256 bits
Maybe they had different Pixel Engines in mind, thus fitting texture data into 256 bits.
We need at least, even thinking about nice caches in the Rendering core like the GS has, 64 bits of texture data per cycle (4x16 bits)
That would elave you with no bandwidth at all for textures, you would have to pull a GS and re-use Pixel Engines as TMUs.
With a 512 bits bus you can have:
4 Pixel Engines each pulling/pushing 64 bits of data for a total of 256 bits
4 TMUs loading 64 bits of data each for a total of 256 bits.
This allows single cycle bi-linear without texture cache (the GS filters from the texture cache) access with 16 bits texels.
On the GS you achieve single cycle bi-linear only if your texture fits the 8 KB Texture Cache on the GS Rendering core: if you break it (texture is too large) the cache is re-filled at 150 GB/s or 8 KB per cycle.
The PSP GPU could do things like this:
If the texture fits the cache you can do bi-linear in a single cycle: if you use 16 bits textures then you could pull them from the VRAM instead of the texture cache and still do not drop to 2 cycles for bi-linear filtering.
This means that you should not expect big textures to kill the PSP GPU if they use 16 bits color depth (you can still produce a 32 bits result from 4x16 bits samples).
BTW, a note on Flipper (GCN's GPU).
GCN's Flipper can only do single cycle tri-linear with 16 bits texels, btw: it takes two cycle with 32 bits texels IIRC.
The TEV (I think it is the TEV that does texture filtering) can load 32x16 bits texels texels (512 bits texture interface) and 32 texels are enough for 4 pixel pipelines (tri-linear needs needs 8 input texels).
