home *** CD-ROM | disk | FTP | other *** search
- Path: informatik.tu-muenchen.de!fischerj
- From: fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: TMapping again!
- Date: 18 Jan 1996 19:05:49 GMT
- Organization: Technische Universitaet Muenchen, Germany
- Distribution: world
- Message-ID: <4dm5md$qfc@sunsystem5.informatik.tu-muenchen.de>
- References: <4d0ou6$835@astfgl.idb.hist.no> <Z31Wx*zA0@mkmk.in-chemnitz.de> <4d42di$9e9@maureen.teleport.com> <4d5lvi$emc@brachio.zrz.TU-Berlin.DE> <4d6v0t$3dt@maureen.teleport.com> <4djj0t$4ni@sunsystem5.informatik.tu-muenchen.de> <4dlo7d$h39@news.cs.tu-berlin.de>
- NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
- Originator: fischerj@hphalle5.informatik.tu-muenchen.de
-
-
- In article <4dlo7d$h39@news.cs.tu-berlin.de>, rawneiha@hydra.zrz.TU-Berlin.DE (Philipp Boerker) writes:
- |> Organization: Technical University of Berlin, Germany
- |> Lines: 71
- |> Message-ID: <4dlo7d$h39@news.cs.tu-berlin.de>
- |> References: <4d0ou6$835@astfgl.idb.hist.no> <Z31Wx*zA0@mkmk.in-chemnitz.de> <4d42di$9e9@maureen.teleport.com> <4d5lvi$emc@brachio.zrz.TU-Berlin.DE> <4d6v0t$3dt@maureen.teleport.com> <4djj0t$4ni@sunsystem5.informatik.tu-muenchen.de>
- |> NNTP-Posting-Host: hydra.zrz.tu-berlin.de
- |> Mime-Version: 1.0
- |> Content-Type: text/plain; charset=iso-8859-1
- |> Content-Transfer-Encoding: 8bit
- |>
- |> fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
- |>
- |>
- |> >|> AAAAAA..........BBBBBCCCCCCDDDDD
- |> >|>
- |> >|> A = x fraction
- |> >|> B = y integer
- |> >|> C = y fraction
- |> >|> D = x integer
- |> >|> . = zero or more precision for x
- |> >|>
- |> >|> as you see the example above work...
- |>
- |> >uhm has anyone actually seen the mapper work ? IMHO the fact that
- |> >CCCCCC y fraction also causes an adress, this could be used imho
- |> >for smoother mapping!
- |>
- |> >I guess you normally use 32 equal pixels
- |>
- |> I think that you rather have the same 32x32 64 times in your
- |> 256x256 texture. This will cause the y fraction to be ignored.
- |>
- |> > but if you'd use 32 values
- |> >beeing interpolated between 2 pix of the "real 32x32 map", then it
- |> >should give you interpolation for free!
- |>
- |> hm.
- :)
-
- |>
- |> >|> : Yes, I agree. Sharon, one of the coders of matrix, is actually a
- |> >|> : PC coder but his polygon engine on a 33 MHz 486 is slower than
- |> >|> : our (Sharon, Grond, Skyphos all/matrix) engine on a 25 MHz 030!
- |> >|> : That's the power of a large register set!
- |>
- |> >well is you polyengine still faster using 8 planes ? ;)
- |>
- |> I was refering to 8bit.
- |>
- |> >he got a non-local-bus vga ? ;)
- |>
- |> Local bus...
-
- ooh =:o
-
- well hm... polygon is just writing 32bit values to vram.
-
- The 030 will do this at on AGA 7MB/sec. Or do you refer to
- A3000+gfx-card ? ;)
-
- average VLBs installed in a 486-33 should have about(?) 15mb/sec speed.
- mhm. is the PC version writing bytewise ?
-
- how much fps ? is it mem overwritten multiple times (fastmem render ?).
- then fastmem speeds cares.
-
- are you sure the PC version is as optmized?
-
- |>
- |> >It depends on the routine if a large register set is needed.
- |> >inner loops can live with x86 chipset, but when it comes to
- |> >2st outer, the L1 caches have to play the role of a larger
- |> >register set.
- |>
- |> But if you have real large register sets and superscalar processor
- |> design you maybe can do 2 rasterlines at once or more likely to frames
- |> for i-glasses...
- ??
-
- |>
- |>
- |> >my friend always argues that you could see the cache as big register
- |> >set on intel
- |>
- |> Then ask him how he does a
- |> "shift left with mask out and insert" rdest,rsource1,rsource2
- |> within 1 cycle from datacache...
-
- can 680x0 do that ? x86 operations with datacache as destination need
- 33 cycles AFAIK. add.l D0,var or in x86 add eax,var
-
- |>
- |> >, but I disagree, a mapper loads so much from mem that
- |> >your variables in cache are bombed by the texture data
- |>
- |> Hm, I don't think that you will set so many pixels, that you can
- |> fill 8k cache before you execute outerloop a second time...
-
- doesn't care how much pix are read in innerloop, scanning a 64k pic
- will destroy cached instructions. don't know how fatal it is.
-
- |>
- |> Greets,
- |> Phil.
- |> ----------------------------
- |> grond/matrix
- |> rawneiha@sp.zrz.tu-berlin.de
- |> ----------------------------
- |>
- ------------------------------------------------------------------------
- fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
-
-