On Aug 23, 2007, at 11:04 AM, Dieter wrote:
It is not obvious to me why OGD needs a large FPGA but we can get by
with a small one. Other than having two heads, what is OGD doing
that
we don't need to?
They are implementing a full blown graphics card with OpenGL. This
takes
up a lot of space.
So an alternate FPGA "firmware" could leave out some OpenGL stuff and
include a video decoder instead.
Yes, exactly. Note that the Ocean Logic designs are no doubt optimized
a lot, so
we might not be able to get the same performance that they can (but
should be
able to get pretty close, i.e. within a factor of two). It will be
interesting to see how
much space the video decoding hardware and OpenGL use up -- if they are
both
small enough, it might be possible to fit them both into TT's ODG with
the XS5000
and synthesize them together as an ASIC.
H.264 is computationally expensive if you are using a CPU.
Even mpeg2 takes a fair amount of CPU to decode.
Yes, that is true, but it is nowhere near as much CPU power as OpenGL
games.
Why not good? Is this very slow?
Yes, it is SLOW. With an FPGA this size, it could take a second or two
to switch
codecs if we have to reload the FPGA bitstream, which would be quite a
lot of
lost time in a situation where one is watching videos in multiple
formats. We would
also have to make sure not too many system critical functions were
performed in
the FPGA so that having it out for a few seconds didn't matter. On the
other hand,
if we could memory map the FPGA and have the DSP stick everything
together, we
would simply be able to execute from a different location in memory and
it would
take nanoseconds to switch codecs.
I think we would still have to reconfigure the FPGA to implement
encoding vs decoding
video, but that is probably an event that is likely to occur much less
often. In a
professional setup where a pro might be evaluating e.g. picture quality
for a certain
codec encoding video, or application of effects, it would be viable to
just buy two and
dedicate one to encoding and one to decoding, and have them both on the
network.
I keep hoping that TI (or whoever) will come out with a faster DSP
and we can do the whole thing in the DSP without an FPGA.
I agree, it would be nice. The only problem is that DSPs have a long
way to catch
up to FPGAs, so it would be more likely to be the other way around ;-(
We could just wait a year for Murphy's Law :-)
This should mean that a DST or DCT (or the inverse) would be faster as
well since these produce only half as much output.
But the more I read, the more confused I get. After a while the brain
will sort it out.
So James, has your brain sorted it out yet? Is Blackfin any good to
us?
Well, I figured I might as well look at it. (Yes, it should mean the
DCT is faster
as well unless it is a 32 vs 16 bit arithmetic problem; but see below,
that benchmark
is not useful.)
From what I see, it is just marketing. They are comparing to the C55x
series; the
64x+ DSP is a really, really sweet machine and is faster than the 55x.
For
example, it actually has twice the number of execution units as the
Blackfin, so
it can do twice as much work, where as the closest the Blackfin gets to
the C55x
is 50% faster.
Look at the first "Speed Scores for Fixed-Point Packaged Processors":
http://www.analog.com/processors/blackfin/overview/benchmarks/index.html
The 64x+ blows the Blackfin out of the water.
Of course, it does cost twice as much...
_______________________________________________
Open-hardware-ethervideo mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-hardware-ethervideo
