From: amlaukka@cc.helsinki.fi (Aki M Laukkanen) Newsgroups: comp.sys.amiga.programmer,de.comp.sys.amiga.misc Subject: Re: DOOMPORTERS: 040/060 wall slow Date: 26 Jan 1998 08:47:59 GMT Organization: University of Helsinki Lines: 52 Message-ID: References: <6ab2iv$61$1@Nordschleife.modem.informatik.tu-muenchen.de> <6ag8jt$7q$1@Nordschleife.modem.informatik.tu-muenchen.de> NNTP-Posting-Host: vesuri.helsinki.fi Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.3.2 UNIX) Path: noticias.ulpgc.es!news.rediris.es!news-ge.switch.ch!feed1.news.luth.se!luth.se!fci-se!fci!newsfeed.sunet.se!news99.sunet.se!news01.sunet.se!193.166.5.150.MISMATCH!news.funet.fi!news.helsinki.fi!amlaukka Xref: noticias.ulpgc.es comp.sys.amiga.programmer:76238 de.comp.sys.amiga.misc:10327 In article <6ag8jt$7q$1@Nordschleife.modem.informatik.tu-muenchen.de>, fischerj@informatik.tu-muenchen.de wrote: >> Yes, this is due to the characteristics and size of the datacache and >> the behaviour of the copyback cache operation. Writing vertically is >> generally a very bad thing(tm) with write-allocating copyback caches. >except having a 319 sized buffer ;) Writing vertically will kill the cache somewhat no matter what height. >is -mmu also doing the "have fastmem acess in c2p" thing ? 040, too ? Imprecise yes although the new phase5 68060 libraries do this automatically and there are some utilities on aminet there might be people not aware of these things. On 040 it won't improve writes (although I kinda got that impression by reading the m68040 users manual) however strangely enough I get 7 MB/s reads from chip now (no use in doom). >oh, only 10% ? the reason is the average wall is less than 64pixel height ? >I wonder. on 040 a 128 height wall would slow down by read+write a >cacheline per pixel. Well Doom is not exactly tmap walls test although it takes cirka 28 percent of frame time on 040. >> Currently also to minimize the counter effect of not having copyback the >> floor and ceiling is drawn with long word writes to long word aligned ÜÜÜÜÜ ÜÜÜÜÜÜÜ >you got the walls do 4 columns a time ? mhm, and top/bottom egdes as >usual ? wasnt that lot of work ? I didn't say that. Columns are written one by one. The catch is that they don't allocate cache lines and the writes go to memory directly. The downside is that although this is definately faster on longer columns (doom terminology) it's slower on shorter ones. >mhm, wouldnt be 319 sizing less programmingeffort and better result ? >imho it should be fastest due to ideal copyback burstwork and no >shifting. Less effort, I don't think so. You might get the rendering to happen to such a buffer with not much sweat but how about other drawing and let's say c2p? And as I said this won't help with long columns either because you run out of cache. 16*200 = 3200 + texture + light tables + other accesses to memory etc. Carmack designed the engine for 486 class systems which have a write through cache. -- D.