Hello Mugdha,
thank you very much for your extensive reply. Your explanations about
POOL and its advantages clarified a lot.
Maybe I should add that, in our research project, reliability is not the
most important target. Since we are not developing a product (but an
embedded object recognition system) interesting experimental results are
the main objective.
In our context, we have "DaVinci-OpenCV" working as a middleware based
on DSPLink. It recieves function calls from arm-linux programs and
forwards them to the DSP. The DSP offers a selection of OpenCV-compliant
functions (not taken from the liibrary itself, but re-implemented and
DSP optimized). Basically, DSP OpenCV functions can be called by reference.
Besides that, "DaVinci-OpenCV" can allocate and free OpenCV Matrix
structures continiously in physical memory. For that, it basically uses
the Bigphysarea kernel functions via a CMEM-like kernel module (the
architecture you also advised). In our case, the DSP does not need to
allocate or free common memory itself, because the ARM knows how much is
needed for a respective operation.
Regards,
Andre
Kamoolkar, Mugdha schrieb:
Andre,
Sorry to have missed your very first e-mail where you mentioned your issues with
DSPLink POOL & CMEM; I look for DSPLink or similar in the title to see if I
need to reply. :-) DSPLink does not use CMEM internally, it just uses the POOL
module, which is independent and not based off CMEM. However, Codec Engine/other
users of DSPLink use CMEM to get physically contiguous buffers, and pointers to
these buffers can be sent to DSP using NOTIFY/MSGQ module. I agree that having the
POOL module work only on fixed size buffer pools is quite inconvenient, but it does
have some advantages:
1. Gives a deterministic behavior over a long period of operation due to
elimination of fragmentation. Basically, having fixed size buffer pools creates
a list of buffers, so the behavior over system execution time will be the same,
if there are no buffer leaks.
2. It makes it very easy to allocate on one processor and free on the other.
Having our own memory manager allows us to implement this functionality. If the
buffers were allocated using the OS-specific memory manager (e.g. malloc), then
we would not be able to provide this functionality.
Also, POOLs can be created dynamically as per need. So if you have different
needs at different times (modes), then you can close a POOL and open it with
different sizes. If this is not ok for you because you have variable buffer
size needs at the same time, and if you are not very concerned about memory
wastage, then one option is to define a max size (e.g. 4096 bytes), within
which you are sure, that all your buffer sizes will fit. Then set exactMatchReq
flag when opening the POOL to FALSE, and just define a large number of buffers
of this max. size. In this case, for any size that you need, that is less than
this max. size, DSPLink will return you a buffer of the max. size. But if
memory wastage is still a big concern to you, and you don't need the capability
to allocate from one processor and free from the other, then finally I would
have given you exactly the same advice as you have done. Write your own kernel
module that will give you variable sized buffers that you can allocate and
free, both from the GPP-side only.
Hope this clarifies things a bit ...
Regards,
Mugdha
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Gaschler
Sent: Tuesday, July 01, 2008 2:09 AM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: Porting OpenCV to DM6446
Hi Jose,
sorry, I have not used opencv for video encoding and decoding yet on the
davinci. (Isn't that what the DSP is for? ;-) There are many general
explanations on installing opencv+ffmpeg, though:
http://freeshells.ch/~phoenix/ocv.htm
Does the configure script ignore ./configure --with-ffmpeg ??
What does
pkg-config --libs ffmpeg
say?
best regards
Andre
[EMAIL PROTECTED] schrieb:
Hi Andre.
I finally did the easy way. I patched the function by removing its content.
Now I'm trying to open an avi file by using cvCaptureFromFile, but it
doesn't seem to work. I traced it and found out that no HAVE_VFW,
XINE, FFMPEG or QUICKTIME were defined because no one of them was
installed on the target. So I tried to install FFMPEG on it, and did it
successfully.
But when I executed again the opencv's configure script to recompile
the library with ffmpeg support, I realize that ffmpeg wasn't detected.
I was able to let configure to know about the presence of the ffmpeg
includes directory, so it generated the following output:
checking ffmpeg/avcodec.h usability... yes checking ffmpeg/avcodec.h
presence... yes checking for ffmpeg/avcodec.h... yes
But finally, in the HighGUI configuration summary, the result was the same:
Use ffmpeg: no
I don't know what I'm doing wrong or even if there is a simpler
solution to open an avi file with opencv...
Thanks in advance and best regards.
Jose
-------- Original Message --------
Subject: Re: Porting OpenCV to DM6446
Date: Tue, 20 May 2008 13:30:45 +0200
From: Andre Gaschler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [email protected]
Hi Jose,
I also stuck at that point. I am sure that the error is due to the old
compiler version of the arm-gcc. What you can most easily do is using
an older version of opencv or simply remove the contents of the
function icvPyrSegmentation (of course keeping a "return CV_OK").
Fortunately, this is the only function in the compile process that
doesnt work and most algorithms do not need it.
If you really want to solve the problem, I would recommend to
- get a new compiler toolchain, which involves compiling gcc and takes
a lot of time if one has never done it before (who knows, maybe its
enough to download the newest version from ti.com??) important: the
davinci architecture is not arm-linux but arm_v5t_le- !
- or write a patch for this opencv funtion (you never know, can be
easy or impossible) Both takes some time so I have not tried so far,
because my face recognition algorithms do not need the function at
all.
I am most interested in how you solve the problem - especially when
you get a new gcc working it would be great to hear how that is done!
By the way, I am still working on porting some opencv functions to the
DSP. I have integrated the bigphysarea patch into the montavista
kernel and rewritten CMEM to dynamically allocate physical memory.
And, dsplink messages are working now. But, of course, it will take
some time to implement it properly. Hopefully, matrix multiplication
or at least convolution on the real opencv matrix structures will work
in a two or three weeks.
-- Andre
[EMAIL PROTECTED] wrote:
Hi Andre,
I'm trying to complete the first step you mentioned, i.e. "make (i)
Opencv work on the ARM-montavista-linux (which I did quite quickly)".
When I try to compile the OpenCV sources, I get the following error
compiling cv/src/cvpyrsegmentation.cpp
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../.. -I. -I../../cv/include -I../../cxcore/include -I../..
-DNDEBUG -Wall -fno-rtti -pipe -O3 -fomit-frame-pointer -MT
cvpyrsegmentation.lo -MD -MP -MF ".deps/cvpyrsegmentation.Tpo" -c -o
cvpyrsegmentation.lo cvpyrsegmentation.cpp; \ then mv -f
".deps/cvpyrsegmentation.Tpo" ".deps/cvpyrsegmentation.Plo"; else rm
-f ".deps/cvpyrsegmentation.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I.
-I. -I../.. -I. -I../../cv/include -I../../cxcore/include -I../..
-DNDEBUG -Wall -fno-rtti -pipe -O3 -fomit-frame-pointer -MT
cvpyrsegmentation.lo -MD -MP -MF .deps/cvpyrsegmentation.Tpo -c
cvpyrsegmentation.cpp -fPIC -DPIC -o .libs/cvpyrsegmentation.o
cvpyrsegmentation.cpp: In function `CvStatus
icvPyrSegmentation8uC3R(uchar*, int, uchar*, int, CvSize, CvFilter,
CvSeq**, CvMemStorage*, int, int, int)':
cvpyrsegmentation.cpp:1021: internal compiler error: in
verify_local_live_at_start, at flow.c:546 Please submit a full bug
report, with preprocessed source if appropriate.
Send email to MontaVista Software, Inc. for instructions.
make[3]: *** [cvpyrsegmentation.lo] Error 1
make[3]: Leaving directory `/home/opencv/tmp/opencv-1.0.0/cv/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/opencv/tmp/opencv-1.0.0/cv'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
make[1]: Leaving directory `/home/opencv/tmp/opencv-1.0.0'
Do you know something about it?
Thanks in advance and regards.
Jose
-------- Original Message --------
Subject: Porting OpenCV to DM6446
Date: Fri, 09 May 2008 13:08:32 +0200
From: Andre Gaschler <[EMAIL PROTECTED]>
To: [email protected]
Hello,
in the previous weeks I have been working on porting OpenCV to the
DM6446. The main target is to make (i) Opencv work on the
ARM-montavista-linux (which I did quite quickly) (ii) Opencv use some
DSP power, namely for those very basic matrix operations. If anybody
does not know Opencv, its basically a computer vision C library
originally made for i86. It both provides basic math and matrix
operations and very newly researched computer vision algorithms.
For now, my main target is to allocate opencv matrix data in common
memory of the DM6446 and rewrite and encapsulate i.e. the matrix
multiplication function of opencv so it calls a procedure on DSP side
(pointers to the matrices by-reference). So, basically I only need
(i) remote procedure calls and (ii) nice access to common memory.
For the former, I am experimenting with DSPLINK that seems to serve
nice remote procedure calls. Do you think it is right not to use the
Codec Engine. What Ive heard CE is specialized on stream processind
and DSPLINK with its modules PROC and NOTIFY/MSGQ is more appropriate
for "normal" RPCs.
For the latter, I cannot really agree with the tools TI provides. I
tested DSPLINK POOL, that only serves fixed size pools that have to
be determines at boot/compile time. The same goes for CMEM (which
DSPLINK uses I think(?)). The memory pools are a good idea for DSP
algorithms with fixed worst-case memory requirements. But not for
usual computer vision algorithms that firstly use *lots* of
structures you are not going to allocate pools for and secondly, do
not have fixed requirements in general.
My most important questions are
- do think its a good idea in general to port opencv to the DM6446
- is there *anything* that can *dynamically* allocate memory (not in
pre-defined pools) so both ARM and DSP can work on it without copying???
Ive got the impression since the DSP does not have a memory
management unit it has got to work on (huge) chunks of continuous physical
memory.
Because if there is no means for dynamically allocate continuous
physical memory I will write a linux kernel module for that (that
replaces CMEM).
Andre
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sourc
e
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
