home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!rosie!next.com
- From: pgraff@next.com (Peter Graffagnino)
- Newsgroups: comp.arch
- Subject: Re: Graphics Systems
- Message-ID: <4398@rosie.NeXT.COM>
- Date: 22 Jul 92 21:43:13 GMT
- References: <1992Jul16.205220.610@darkcube.radig.de>
- Sender: news@NeXT.COM
- Lines: 38
-
- In article <1992Jul16.205220.610@darkcube.radig.de> vhs@darkcube.radig.de
- (Volker Herminghaus-Shirai) writes:
- > In article <GLEW.92Jul14233412@pdx007.intel.com> glew@pdx007.intel.com
- (Andy
- > Glew) writes:
- ...
- > > NeXT No coprocessor
- > > ...
- >
- > This is not quite right. As far as I know, NeXT has a custom chip doing
- raster
- > copies to/in the video ram. This is not exactly block-move, but more like
- BLT.
- > It's not what you would call a graphics system, but since the original
- thread
- > was about block-move I thought I'd throw my $0.02 in.
- >
- > P.S, Andy, my .sig is not meant personally!
- > --
- > Volker Herminghaus-Shirai (vhs@darkcube.radig.de)
- >
- > If I had intel inside(tm), I'd throw up...
-
- Actually, we have no such coprocessor, all compositing (blitting) is done
- with the host CPU. Our model is to have a high-bandwidth memory subsystem
- where VRAM and DRAM are peers with the same performance characteristics.
- Since NeXTSTEP tends to draw in window backing stores (DRAM) just as
- frequently (if not more) than VRAM, its hard to see how a graphics
- accelerator can help (unless it has its own DRAM/VRAM virtual memory
- subsystem with a CPU/MMU (ala NeXTdimension)). With this CPU-centric
- graphics architecture, your graphics performance rides the same (steep)
- curve as your general CPU performance -- customers like it when
- *everything* gets faster when they upgrade to a faster CPU.
-
-
- Peter Graffagnino
- Graphics Software
- NeXT Computer, Inc.
-