Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pacbell!att!alberta!calgary!radford From: radford@calgary.UUCP (Radford Neal) Newsgroups: comp.arch Subject: Re: RISC bashing at USENIX (speed of graphics with SPARC) Summary: Perhaps its the frame buffer's fault Message-ID: <1747@vaxb.calgary.UUCP> Date: 15 Jul 88 19:53:32 GMT References: <6965@ico.ISC.COM> <936@garth.UUCP> <202@baka.stan.UUCP> <204@baka.stan.UUCP> Distribution: na Organization: U. of Calgary, Calgary, Ab. Lines: 14 In article <204@baka.stan.UUCP>, landru@stan.UUCP (Mike Rosenlof) writes: > ...In this isolated case, SPARC ( or at least this implementation > by Fujitsu ) is not impressive, especially when comparing costs to a > 68020 system. This is one of the difficulties of very simple graphics > like this, lots of data has to be moved around... It's possible that we're all missing the point here. Could it be that the time for simple graphics on both the 68020 system and the SPARC system was dominated by the access time of the frame buffer? That no processor of any speed could have speeded the graphics up? Was the frame buffer the same in the two cases? Radford Neal