Path: chuka.playstation.co.uk!news From: Robert Swan Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Caches Date: Fri, 14 Aug 1998 17:39:31 +0100 Organization: I wish! Lines: 48 Message-ID: <35D46843.5DF5@mdx.ac.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> <35D44CBE.1FA95769@ndirect.co.uk> NNTP-Posting-Host: nova.mdx.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u) Alex Herbert wrote: > 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. Are there any examples of using the d-cache? Im sure Ive seen some pages with it on, but Its been so long since I went through the pages... first Ill check the faq and see if its mentioned though :) If it speeds up gssortobject4() i could do with that as im doing a fair amount of that in my game (does it work on a per primitive type, or per gssortobject4 call?) Ill leave the i-cache alone methinks This idea of the fast graphics ram has me worried. Ive got a fair understanding of texture pages, and this is why ive got all my textures on one texture page in vram to avoid 'thrashing the texture cache' as it is called by some!. This ties in with what you said about if you have all the same texture in a row in the otable its faster than when interleaved stuff that requires for another texture page to be read in by this fast graphics ram. My knowledge of this doesnt match with the idea of needing repeated reads from the vram when using textures though, so are the graphics a three stage process? copy from vram into texture cache (the 256x256 tpage stuff) copy from texture cache into this faster graphics ram copy from faster graphics ram to vram again (where buffers are) I thought it was just two stage, but then again Ive just thought back to the problems I had rotating large sprites and it slowing down tremendously which doesnt fit in with this idea... are you suggesting that mapping a large texture to say a 16x16 pixel area on screen takes longer to draw than a smaller texture because of something to do with the size of the graphics ram and needing to read more often to cover the whole area of the larger texture? I presume it might take longer but not because of the texture cache (which is 256x256 pixels big). Im not so clear about this now. My intuition says that drawing a 32x32 texture to say fill the screen should take exactly the same time as drawing a 64x64 texture (at least in terms of read/writes from the texture cache) Rob rs108@mdx.ac.uk