Path: chuka.playstation.co.uk!news From: Alex Herbert Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Caches Date: Fri, 14 Aug 1998 18:34:04 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 77 Message-ID: <35D4750C.A4613436@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> <35D44CBE.1FA95769@ndirect.co.uk> <35D46843.5DF5@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: > 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?) > Per GsSortObject4(). Simply insert 0x1f800000 as the scratchpad address in GsSortObject4(). (Chances are that's what you have already.) BTW the D-cache is 6 times faster than normal RAM. Some people like to stick the stack in the d-cache temporarily to speed up section of code. I haven't tried this myself as I haven't come accross a situation where it would be appropriate, but it can cause all sorts of problems if you don't know exactly what you're doing. 1K is a bit small for a stack. > Ill leave the i-cache alone methinks You don't need to think about it - it's automatic and you're already using it. Just bear in mind that unrolling loops often doesn't give the desired effect. > 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) > Again, this cache is automatic and it happens within the bowls of the PSX. You don't need to do anything except remember it's there. I can't remember the size of the cache but I'm sure it's actually much smaller than a tpage. (Something like 32x16 pixels - anyone?) I think you're confusing a tpage with the texture cache. > 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) Sort of. Without the details of the cache size to hand, I can't give you a definitive answer. But this is how the process works. If you use a large poly with a small texture, then many of the pixels in the rendered poly will share the same pixels in the texture. This is where the cache kicks in and speeds up GPU processing. The same goes for expanded/rotated sprites. In the process of GPU drawing it will have to read the same pixels more than once. If the texture is small, it is more likely that when the GPU goes to read a pixel, it will already be in the cache due to an earlier read. If the texture is large, it is likely that when the GPU goes to read pixel data, it won't be in the cache and the GPU will have to read from the slower VRAM. I'm not sure that all makes sense, but I know what I mean. Is that clear for you? Herbs