Path: chuka.playstation.co.uk!news From: Craig Graham Newsgroups: scee.yaroze.programming.libraries Subject: Re: D-Cache Date: Tue, 21 Jul 1998 11:11:40 +0100 Organization: Intelligent Research Lines: 26 Message-ID: <35B4695C.C29FB50D@hinge.mistral.co.uk> References: <359E82E9.1134@dial.pipex.com> <01bdafbf$5c177f20$f2e832a2@gbain.wav.scee.sony.co.uk> <35AF051F.708C@dial.pipex.com> <35AF1307.C1D4198B@scee.sony.co.uk> <35B33151.6DE1D612@easynet.co.uk> <35B34475.D898F644@scee.sony.co.uk> NNTP-Posting-Host: 194.131.235.3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.03 [en] (Win95; I) James Russell wrote: > If you want to process a global/static array, it's going to be stored on the heap and so you'll have > to transfer it to D-Cache before you start, and transfer it back after you finish. This transfer > overhead is only worth it if you're going to be accessing each element of the array more than twice. > This is certainly the case if you're doing some image processing (like the flame/water effects). An example where you can usefully use D-cache in this way is in a simpleenvironment/chrome mapper. As you generate the transformed vertex normals, write them out to the D-Cache. As you will probably use each transformed vertex normal several times (once for each poly that uses the vertex), you get a speedup as you aviod the usual main memory load/stall problems for one set of the data.... Also, as it's data that you are generating anyway, there isn't the copy-in overhead that James mentions above - you would have had to do the write anyway, might as well do it to the quickest place... > James Craig. (yes, I know it's a marginal one when you use lib calls to do the normal rotation, but hey, it's there)