Panajev2001a
Veteran
I am considerign especially PlayStation 3 and the possiblity of having 32 MB of e-DRAM ( plus there are some Image Caches on each Processor Element for the Visualizer chip... they might be used for temporary textures storage or something else... to store VQ tables maybe ? 
)...
I will think about tiling the screen in 4 parts so that each PE can work on one of them... each PE processes a separate polygon ( efficient with very tiny polygons... pixel or sub-pixel sized polygons ).
all in all it will result that basically it is almost like we considered one big front-buffer and one big back-buffer.
Let's think 1280x720p ( which has 3x the amount of pixels than 640x480p so aliasing is already reduced ) and let's think about 4x AA.
Front-Buffer = full size at 24 bits, 8:8:8 R:G:B... no destination alpha.
Z-buffer = full size and 32 bits precision.
Back-buffer = extra-large size ( 4x AA... 2x Horizontal and 2x Vertical ) at FP24 per color component ( RGBA ).
Back-buffer = 1280 * 720 * 4 * 12 bytes ( FP24 RGBA ) = 44 MB
Front-buffer + Z-buffer = ( 1280 * 720 ) * ( 3 + 4 ) = 6 MB
Total memory needed = 50 MB
This would leave 14 MB for pure texture space if we had 64 MB of e-DRAM.
To fit 32 MB constraints we would have to lower the FP precision of the back-buffer or to lower the AA to 2x AA ( would cut the Back-buffer in half ).
I'd rather keep the FP Back-buffer...
Back-buffer = 22 MB
Total memory needed = 28 MB
This would leave 4 MB of space for textures and with good texture compression and using procedural textures when available we should be fine.
Worse comes to worse we can JPEG or VQ compress them and uncompress them using the APUs.
Do not forget that the Visualizer can still stream textures and the bandwidth to the external memory is a non insignificant as Rambus' Yellowstone can provide 25.6 GB/s ( about 21.3x the bandwidth that there is between the GIF and the GS in the PlayStation 2 and on PlayStation 3 Vertex data should not come from the external memory, but it should pass through direct bus between the Broadband Engine and the Visualizer and that would be fatter than the pipe between the Broadband Engine and the external Yellowstone DRAM ).
I do not see why you should not use Texture Streaming on PlayStation 3 if it can help you
In average the dynamic ( for streaming in and out textures ) on a lot of PlayStation 2 titles is ~1 MB ( another ~1 MB or less is used for static texture storage )... we are talking about an increase that goes from 2x to ~4x for space in e-DRAM to stream textures and we now have much more bandwidth to the GPU and we can have better than standard 8 bits CLUT compression.
I hope not to have made too much fuzzy math ( after this post some nice JFET and BJT transistors wait for me... exam coming up tomorrow )...
If we were doing 4x AA at 640x480p...
Back-buffer = ~14 MB
Front-buffer + Z-buffer = ~2 MB
Total memory needed = ~16 MB
We have then ~16 MB for textures.
)...I will think about tiling the screen in 4 parts so that each PE can work on one of them... each PE processes a separate polygon ( efficient with very tiny polygons... pixel or sub-pixel sized polygons ).
all in all it will result that basically it is almost like we considered one big front-buffer and one big back-buffer.
Let's think 1280x720p ( which has 3x the amount of pixels than 640x480p so aliasing is already reduced ) and let's think about 4x AA.
Front-Buffer = full size at 24 bits, 8:8:8 R:G:B... no destination alpha.
Z-buffer = full size and 32 bits precision.
Back-buffer = extra-large size ( 4x AA... 2x Horizontal and 2x Vertical ) at FP24 per color component ( RGBA ).
Back-buffer = 1280 * 720 * 4 * 12 bytes ( FP24 RGBA ) = 44 MB
Front-buffer + Z-buffer = ( 1280 * 720 ) * ( 3 + 4 ) = 6 MB
Total memory needed = 50 MB
This would leave 14 MB for pure texture space if we had 64 MB of e-DRAM.
To fit 32 MB constraints we would have to lower the FP precision of the back-buffer or to lower the AA to 2x AA ( would cut the Back-buffer in half ).
I'd rather keep the FP Back-buffer...
Back-buffer = 22 MB
Total memory needed = 28 MB
This would leave 4 MB of space for textures and with good texture compression and using procedural textures when available we should be fine.
Worse comes to worse we can JPEG or VQ compress them and uncompress them using the APUs.
Do not forget that the Visualizer can still stream textures and the bandwidth to the external memory is a non insignificant as Rambus' Yellowstone can provide 25.6 GB/s ( about 21.3x the bandwidth that there is between the GIF and the GS in the PlayStation 2 and on PlayStation 3 Vertex data should not come from the external memory, but it should pass through direct bus between the Broadband Engine and the Visualizer and that would be fatter than the pipe between the Broadband Engine and the external Yellowstone DRAM ).
I do not see why you should not use Texture Streaming on PlayStation 3 if it can help you
In average the dynamic ( for streaming in and out textures ) on a lot of PlayStation 2 titles is ~1 MB ( another ~1 MB or less is used for static texture storage )... we are talking about an increase that goes from 2x to ~4x for space in e-DRAM to stream textures and we now have much more bandwidth to the GPU and we can have better than standard 8 bits CLUT compression.
I hope not to have made too much fuzzy math ( after this post some nice JFET and BJT transistors wait for me... exam coming up tomorrow
)...If we were doing 4x AA at 640x480p...
Back-buffer = ~14 MB
Front-buffer + Z-buffer = ~2 MB
Total memory needed = ~16 MB
We have then ~16 MB for textures.
