lawrence@quintus.UUCP (Lawrence Byrd) (03/25/89)
Most of the recent discussion of the i860 has been concerned either with its use (and possible problems) as a general microprocessor or with the new heights of benchmarking extravagance that may have been achieved. However a major part of the design intent (if not the subsequent marketing intent) for the i860 was as floating point and graphics co-processor. My question is how good is the i860 as a graphics co-processor and how does it compare with other possible solutions, such as the Intel 82786 and TI 34010 graphics chips? Areas of comparison might include cost, capability, level of circuit integration, ease of attachment etc. Is the i860 any sort of breakthough in this area and will it change how system builders add graphics acceleration to their boxes (or how much they charge for it)? Clearly one possible breakthrough is if one does use the i860 as the primary CPU, then you *might* get significant graphics acceleration thrown in for free (so to speak) resulting in lower-cost workstations? Another possible breakthrough *might* be that the ease of integration with the 486 will make the i860 the graphics accelerator of choice in 486 based systems? This question is motivated by the increasing complexity of window systems and the obvious need for ways of speeding them up. It is depressing that one needs a system in the 5 to 10 MIP range before the newer window systems (such as various toolkits on top of X) start responding crisply. I am impressed, for example, by the Bell Tech Blit board which uses an 82786. Plugged into a fairly low-MIP 16Mhz 386 system, it gives better X Windows performance than many workstations we use. So the obvious question is: will the i860 radically change (improve) any of this? Lawrence Byrd sun!quintus!lawrence This is reduced-disclaimer Quintus (415) 965 7700 two-line signature.
henry@utzoo.uucp (Henry Spencer) (03/26/89)
In article <977@quintus.UUCP> lawrence@quintus.UUCP (Lawrence Byrd) writes: >This question is motivated by the increasing complexity of window systems >and the obvious need for ways of speeding them up. It is depressing that >one needs a system in the 5 to 10 MIP range before the newer window systems >(such as various toolkits on top of X) start responding crisply... The cynic would say that we need less-baroque window systems. The one on AT&T's Blit responds crisply with a lousy little 68000 running it. Now that we've got RISC hardware, the next thing we need is operating systems and window systems to match. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jesup@cbmvax.UUCP (Randell Jesup) (03/29/89)
In article <1989Mar25.222551.9141@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <977@quintus.UUCP> lawrence@quintus.UUCP (Lawrence Byrd) writes: >>This question is motivated by the increasing complexity of window systems >>and the obvious need for ways of speeding them up. It is depressing that >>one needs a system in the 5 to 10 MIP range before the newer window systems >>(such as various toolkits on top of X) start responding crisply... > >The cynic would say that we need less-baroque window systems. The one on >AT&T's Blit responds crisply with a lousy little 68000 running it. Half of the problem is "baroque" (otherwise known as Berkeley disease) windowing systems, the other half is the cost of context switching between the windowing system and the processes using it. The second problem can be dealt with using threads (as demonstrated by the Amigas Intuition windowing system). The first problem is one of design - keep efficiency and user response time/drawing artifacts in mind when designing - don't design by committee, and don't build baroque systems on top of other baroque systems. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup