Path: chuka.playstation.co.uk!news From: Alex Herbert Newsgroups: scee.yaroze.programming.2d_graphics Subject: Caches Date: Fri, 14 Aug 1998 15:42:06 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 40 Message-ID: <35D44CBE.1FA95769@ndirect.co.uk> References: <35C81A30.4ACB@club-internet.fr> <35C82DDB.3E12E37C@scee.sony.co.uk> <01bdc061$2c186980$f30b0a0a@Angela1.intelligent-group.com> <35D2E01D.5CA1@mdx.ac.uk> <6r0vps$n7i6@chuka.playstation.co.uk> <35D43404.282A@mdx.ac.uk> <35D438D2.908C3316@ndirect.co.uk> <35D43F08.36BA@mdx.ac.uk> Reply-To: aherbert@ndirect.co.uk NNTP-Posting-Host: dialin2-22.ndirect.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (Win95; I) Robert Swan wrote: > I should really know better than to talk about how C is compiled as I > dont really have a clue :) All this stuff about d-cache and all that, > what a waste of time. (only kidding, im sure its worth it!) I think I can help a little here. The D-cache is basically a 1K section of fast memory which is free for you to use. It is most useful with the GsSortObject4() function which needs a scratchpad area of memory. Other than that you're probably best off leaving it alone until you really know the PSX inside out. Especially as it appears that many of the libs functions trash the D-cache. Then there's the I-cache (or Instruction cache). It's not directly controllable from code. It's purpose is to store the most recently used instructions in faster RAM, so loops etc can execute more quickly. This is why unrolling loops can actually make code slower. Then there's the GPU/VRAM cache (of which I can't remember the name or details off hand). When the GPU draws textured polys or scaled/rotated sprites, it has to make repeated reads of the texture in VRAM, and this cache improves the speed of drawing enormously. This is why a polygon with a small texture will draw quicker than with a large texture, even though the number of rendered pixels will remain the same. With 2D stuff you can get huge GPU performance increases by using this cache effectively. E.g. suppose you're writing a shooter in which you may be displaying numerous 8x8 bullets on screen at any one time. If you sort all your bullets at the same unique priority, the GPU will draw all the bullets in bulk (as they will all appear in the OT together). After the first bullet is drawn, there will be a complete copy of it in the cache, so the subsequent bullets will draw much faster. If, however, the bullets are interleaved with other data in the OT, then the GPU will have to read the VRAM directly each time - which is slower. > Seriously though, theres so much to know and Im not really that > technical so its nice for these things to be brought to my attention, > seeing as quite a lot of programming is counter-intuitive. Hope this sheds some light. Herbs