[manticore] 3d graphics multiprocessor

[Yann Guidon]

hello,

Jeff Mrochuk wrote:
> 
> 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.

F-CPU is a SIMD superpipelined microprocessor code that we're designing.
I have no idea how to integrate it with Manticore but it is designed
to have a lot of horsepower. Here is a little example of the code,
http://www.f-cpu.seul.org/whygee/dct_fc0/dct_fc0.html
and i am preparing new papers. Just explore http://www.f-cpu.seul.org/
to see what we've done so far (VHDL at http://www.f-cpu.seul.org/new/
for example). You can also find there the lastest versions of the
manual (which lags a lot, but has some useful informations).
Just in case you don't know, F-CPU is a "64-bit minimum" machine
so it can handle large SIMD words in the future. With its 64 orthogonal
registers, it's adapted to heavy loads.

One of the remarks i have about Manticore is that AFAIK there is no
support for "blitting", doing ROP2 operations on screen tiles
(moving one screen block to another, maybe hidden, and apply a
boolean operation on the result). While F-CPU is designed to do that
(and much more) happily, it's a big overkill...

However, sending vertices to the 3D engine's FIFO is straightforward,
using the Special Register's interface ("put" and "get" instructions
to an independent, synchronous addressing space).

i'd be happy to learn more about Manticore and discuss with you.

> -Jeff
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~