a few questions
rjo__
Posts: 2,114
Howdy
I was originally drawn to the Prop1 because I thought that I might be able to use it to develop
a project... which you could call a life-long source of irritation, because I have found every avenue
to successful completion block some combination of missing talent or missing information. The reasons
always changed, but the fact remains that I've always wanted to do something that I have just
never been able to pull off.
I am almost convinced that the Prop2 has the right stuff and that I should throw myself
back into my never ending chase:)
This doesn't really matter but with regard to HDMI input:
As I understand the standard a 30 bit 1920x1080 source can be supported by a 165MHz clock and about 18 pins:
Can I get a Prop2 to have a 165MHz clock?
There are 3 sets of differential inputs and assorted control utilities.
Does this all imply that the Prop2 should be able to take an HDMI signal and store it directly to SDRam in a lossless fashion?
With regard to a multi-Prop2, what is the likely limit when one Prop2 broadcasts data to a farm of Prop2's simultaneously...
that is if we just hook up a series of Prop2's to a 32 channel bus, how many can we hook together and still have them operate simultaneously on the same data.
Do they have to be on the same PCB to keep distances short or can they be connected by shielded cables?
Would current limiting resistors be required... if so where?
Finally... I try to keep up with the Prop2 forum, but I have no sense of the next critical date.
Thanks,
Rich
I was originally drawn to the Prop1 because I thought that I might be able to use it to develop
a project... which you could call a life-long source of irritation, because I have found every avenue
to successful completion block some combination of missing talent or missing information. The reasons
always changed, but the fact remains that I've always wanted to do something that I have just
never been able to pull off.
I am almost convinced that the Prop2 has the right stuff and that I should throw myself
back into my never ending chase:)
This doesn't really matter but with regard to HDMI input:
As I understand the standard a 30 bit 1920x1080 source can be supported by a 165MHz clock and about 18 pins:
Can I get a Prop2 to have a 165MHz clock?
There are 3 sets of differential inputs and assorted control utilities.
Does this all imply that the Prop2 should be able to take an HDMI signal and store it directly to SDRam in a lossless fashion?
With regard to a multi-Prop2, what is the likely limit when one Prop2 broadcasts data to a farm of Prop2's simultaneously...
that is if we just hook up a series of Prop2's to a 32 channel bus, how many can we hook together and still have them operate simultaneously on the same data.
Do they have to be on the same PCB to keep distances short or can they be connected by shielded cables?
Would current limiting resistors be required... if so where?
Finally... I try to keep up with the Prop2 forum, but I have no sense of the next critical date.
Thanks,
Rich
Comments
hdmi input is not practical with a prop2.
Running p2 (real chips) at 165MHz should not be a problem.
Storing 1080p even at 25hz is a big problem.
Even if that became barely possible, there would not be any memory bandwidth left to do anything with the data. Each frame would be ~8MB, so a 32MB SDRAM could store 4 frames, and not have time to do anything with it.
For this kind of application, you should think about using an FPGA that supported DDR3 or higher, with native handling of lvds (or other very high speed) serial links.
Thanks for the quick reply... and I agree that an FPGA memory controller would add a lot of functionality.
My basic "architecture" is memory intensive... so the more memory, the faster the memory, the better.
If it were available, I would build a system using an FPGA memory controller. But developing it is beyond my skill set.
Unless someone does it and describes exactly what he did, in a multi-dvd book, I would be
searching for clues for a long time:)
In my holy grail application, I need multiple Prop2's to have simultaneous access to image data, one frame at a time.
As I said, the ability to actually do this with HDMI really isn't critical... knowing that the Prop2 is actually capable of handling the raw data rate is the issue.
This fact gives me a benchmark and let's me think about the other constraints. And being able to use an HDMI signal source is very, very convenient.
Here is the work flow:
Simultaneously Grab
Process
Transmit Sparse Data from Processes
Analyze
Repeat
The ability to actually do this with a full HDMI signal really isn't critical... knowing that the Prop2 is actually capable of handling the raw data rate is the issue.
It looks like the answer is "just barely." Which is fine with me:)
Which get's me back to one of the other issues: given a pile of Prop2 modules, can an idiot build a supercomputer?
How many Prop2s can I slap together before a signal coming out of one them is no longer simultaneously clear to the others?
There has to be a limit...where is that limit in a practical world involving someone like me doing it:)?
Rich
Using an FPGA with something like DDR3 is pretty much a necessity due to the data rates involved. See http://opencores.org/project,ddr3_sdram for some VHDL code.
Even with an FPGA doing the frame grabbing to DDR3, you would have a tough time doing a meaningful amount of processing on the frame buffer even with multiple P2's. That said, it does not sound impossible, just very difficult and EXTREMELY expensive to do.
Regarding a super computer from P2 modules - that depends on what you define as a super computer. How many billions of ops per second? How much floating point capability is needed? (Remember, the P2 does not have hardware floating point). Of course the interconnect scheme is also important
It would be quite possible to build a parallel machine for exploring programming highly parallel systems, however it would not reach current supercomputer performance levels - which are in the terra flop range. To explore somewhere near that territory, you best bet is a cluster of x86 boxes with high end video cards (google CUDA)
I can limit the problem to Prop2 capabilities. Just trying to figure what they are:)
I can understand you not wanting to talk about what you actually want to do (the process & analyze part), however P2 would have real problems even digitizing 1080p30, never mind doing any processing or analysis.
Grabbing the component video with flash ADC's is possible, but for processing/analysis you will likely need to convert to an RGB color space, either with external analog circuitry, or with code ... but code requires a lot of processing per pixel.
I strongly recommend you start small - for example 640x480 - prove your idea to yourself, get the software running at that resolution, then think about scaling up. If this is for developing a potential product, once you had a 640x480 version running, you could use that to start a kickstarter campaign to get funding for a 1080p version ... which would be very expensive.
Heck, you could start with NTSC in to prove the concept!
p.s.
It sounds like potentially neat project. Once you had enough funding, I'd be happy to consult on the project for you, feel free to PM me or email me at "mikronauts" at-symbol "gmail" dot com.
A cursory look at the situation tells me we have 80MIPS times 8 cores = 640MIPS per Propeller.
We can divide that by perhaps 4 for executing code from HUB. That's 320MIPS.
When talking super computers the metric is FLOPS. Floating Point Operations Per Second. So divide by at least ten again. That's 32MFLOPS per Propeller.
So put a hundred Propellers together and we may have 3GFLOPS. That might be on a par with a modern desktop PC.
Except, a hundred Propellers would need some cunning Prop to Prop communications to make those FLOPS useful. So divide by a hundred or a thousand again to account for that.
Ooops we are back to 300 or 30MFLOPS.
We need more Props.
But then we need more communications....We may never catch up with the performance of even a desktop PC never mind a super computer!
I think the reason is that the prop, prop II, or pretty much any mcu is pretty simple to work with from a wiring and electrical point of view.
Wiring a bunch of these together is within the realm of possibility for most people inclined to want to do such a thing, where creating your own board for something like the CPU from a modern desktop would be next to impossible.
C.W.
I love your work.
I don't have a problem discussing it. Anything I do would be right here:) Explained as well as I could explain it.
Years ago I came up with a new stereo-analysis algorithm. I say this because I reviewed the available algorithms with
the head of image processing for DARPA... and according to him, it was new:)
In the intervening years, I have seen others implement very similar strategies, so it is no longer new.
I used to love to play with the algorithm, there were lots of parameters to set and I was fascinated with trying to find
a way to make it more efficient and less operator dependent.
At one point Disney approached me and asked for an analysis... which we provided. And their comment was "there is too much
resolution for this to be true:)
I even had Apple interested at one point... but at that precise moment, everything blew up on us and we couldn't get the thing
to work.
The purpose of the basic algorithm is pixel mapping of left image to right. This together with some knowledge of the optics, gives a
very nice 3D data set.
The problem with the algorithm is that it is very slow, because every possible match is considered. And it is memory
intensive. The meta-data can be many times the size of the original data.
No doubt, I wouldn't be shooting for full HDMI resolution, but I would like to use HDMI for acquisition of single images.
The basic idea doesn't depend upon area statistics or edge mapping. And when I get around to implementing it and
throwing it into the P2 OBEX, it will be pretty clear just how simple or complex the process can be made.
If you think of a flood fill routine, that is used on subtractive images (R-L) at various offsets, you get the basic idea.
The algorithm is perfect for massive parallel computation...The P2 is just about perfect. The only way to improve on the P2, would be to
get rid of all the instructions that I don't need... I'm sure that Chip would be happy to do this for me in his spare time:)
Heater... boys will be boys. More is better.
C.W. exactly
Rich
Very cool!
Thank you for the explanation, it helps to see what you are trying to do, and I can see where it would be a lot of fun.
In your shoes, I'd start with:
- two 640x480 "vga" camera module, use the R5G6B5 mode, P2 will handle the 25MB/sec (possibly 50MB/sec @ 16 bits, not sure, don't have one of the modules yet
- they connect to one of Chip's modules with SDRAM, to filter/decimate the data
- N more modules, talking to the digitizing one, where N = 4 or 9 (not enough pins left for comm channels to more modules)
This will let you evaluate if 640x480 is doable with a reasonable number of props. If it is faster than you need, increase the resolution
If it is slower, drop the frame rate until it is fast enough.
If that is still too slow, drop the resolution.
Fun project! I hope that you keep us up to date, and that it works.
(here, I'll try an invocation of the forum gods for you...)
"A 1080p version is CLEARLY IMPOSSIBLE with Prop2 (without big FPGA/DDR3)"