Main Page   Modules   Alphabetical List   Data Structures   Data Fields  

PlayStation 2 fill-rate considerations
[Restrictions]

The fill-rate attained by the GS, may be (significantly) adversely affected by the following three things: The common underlying reason for the detrimental effect of each of these three cases is that they all increase the number of page breaks which occur during rasterization. The framebuffer is divided into pages (each page is in fact shared between the framebuffer and ZBuffer) and textures are also divided into pages. Large polygons cause page breaks per span between framebuffer pages. Large textures cause one or more page breaks per span between texture pages. Trilinear filtering causes one page break per pixel when the two mip levels currently in use reside in different memory pages.

The exact dimensions of memory pages (these vary with framebuffer, texture and z-buffer formats) are detailed in the GS manual. RenderWare attempts to pack all the mip levels of a given texture into as few pages as possible. As a reference point, all the mip levels of a 64 by 64, 8-bit texture will fit into one memory page (so there would be no penalty for trilinearly filtering such a texture).

Textures may be shrunk by palettizing them (4-bit and 8-bit palettes being supported on PlayStation 2). Tesselation of geometry may in some circumstances cause it to be renderered more quickly, since the extra transformation and lighting cost incurred by the increased vertex-count may be outweighed by the improvement in fill-rate. Also, vector code may be able to use dual-pass alpha-blended rendering to approximate trilinear filtering. Again, this will submit more triangles to the GS but (depending on the exact details of the circumstances) may still end up rendering quicker because it will avoid per-pixel page breaks.

Criterion Software © 1993-2003 Criterion Software Limited. All rights reserved. Built Tue Apr 22 12:46:24 2003. Send Feedback
Converted from CHM to HTML with chm2web Pro 2.85 (unicode)