[manticore] 3d graphics multiprocessor

[Jeff Mrochuk]

I've actually had someone recommend we try using a RISC processor for
vertex operations (all the floating point stuff) and I think its quite a
good idea.

Memory on the other hand in our system is handled entirely parallel to
everything else.  Fill rate (like you said) is really important, so we
have our own memory controller which is running all the time, unlike say
a microprocessor which does things sequentially.  

Basically adding a microprocessor for math and other tasks would be
helpful if the clock was fast enough to keep ahead of the rendering
core.

Something to look at.

-Jeff

On Tue, 2002-06-18 at 00:49, Jason Watkins wrote:
> Apologies if this is considered off topic, there are few communities around
> that deal with gfx hardware design.
> 
> I've been wondering for a while why someone doesn't develop a graphics chip
> based on a multiprocessor design. Take an appropriate memory architecture, a
> decent performance IEEE single precision core, and stir in the rest of the
> DAC, bus control, etc you'd need.
> 
> The concept being that for a small R&D effort, spending time on an instanced
> ALU and implimenting algorithms in software where they are easily revised
> without hardware costs would be a winning strategy.
> 
> I've found some work on this from the stream multiprocessor crowd, however,
> their memory architecture handles random access to small working sets
> poorly, something that is *very* nessisary for good fill rate from texture
> mapping. I don't think there's any real reason a stream like architecture
> could be combined with appropriate caches.
> 
> So I was wondering if any of you had thought along these lines, knew of work
> along these lines, or immediately know why it is an approach doomed to
> failure.
> 
> jason watkins
> 
> 
>