Using the card, however as something more than graphics it might be
useful.
For example as a physics processor. The processor uploads the
program, sets it
running, data goes up to the card & then back to main memory...
As mentioned here:
http://www.fpgacpu.org/usenet/fpgas_as_pc_coprocessors.html
There is a problem with this sort of "Lets do some really quick
algorithm on an FPGA that was sent from the CPU" approach. This is
the key:
> given a semi-autonomous problem which either fits
> in the FPGA and local storage, or which can employ DMA to stream data
> into or through the FPGA without much CPU intervention or management.
If you can give a description of the scene (OpenGL), a small value
actually sent (4096 bit key, or similar, for Cryptography), or data
from outside source (DAQ), then it makes FPGA processing viable. If
you are trying to offload anything that requires much math to the
FPGA, it is simply not possible to wait for the "glacially slow" PCI
bus. Solution: Use PCIe! on a PCIe 32x slot, 16GB/s should be enough
for most applications... Until that is implemented, however, we
should try to find other uses that are not involved with sending lots
of discrete packets.
If you offload entire designs to the FPGA, it is worth the wait
(especially with DMA), but if every time you need to compute an FFT
with [EMAIL PROTECTED] you send across the PCI bus, it is just too slow.
With the physics processor, if you upload an entire scene (which I
assume you are doing) than it is far faster than the CPU.
There are bound to be lots of other uses which require a whole bunch
of math but don't require a constant data stream...
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
