Typically, the 'creation parameters' will provide enough context to allow an
algorithm to declare their "worst-case-for-this-use-case" memory requirements.
The creation params are passed in from the application to the algorithm via the
IALG_Fxns.algAlloc() function - which is also the fxn through which the alg
returns its memory requirements.
For example, image decoders will often have maxHeight and maxWidth fields in
their creation parameters which the calling application must provide. Given
that, the algorithm can respond with its internal memory requirements.
In your case, you may find that you can declare your alg's memory requirements
as a function of some creation param that will help your alg constrain and
declare its worst case mem usage.
Hope that helps - we may need a little more detail if you need a more relevant
example.
Chris
________________________________
From: Cheng Yang [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 10:19 PM
To: [email protected]; Ring, Chris
Subject: Re: Memory operation in the DSP side
Thanks! Your answer is very helpful !
I want to use malloc() because our algorithm is very complicated. It is
difficult to determine how much memory is needed. I mean the memory needed is
dynamic for different input data. Therefore it is not convenient to allocate
the memory in advance. How do you solve the problem? Requesting a buffer large
enough in algAlloc() ?
----- Original Message -----
From: Ring, Chris <mailto:[EMAIL PROTECTED]>
To: Cheng Yang <mailto:[EMAIL PROTECTED]> ;
[email protected]
Sent: Friday, March 28, 2008 11:37 AM
Subject: RE: Memory operation in the DSP side
In a closed system, where you only have to interoperate with
yourself, you can do whatever you want. I don't think there's any limitation
in Codec Engine or BIOS that will prevent you from calling malloc/free from
within your algorithm.
Your algorithm would obviously fail any xDAIS validation
testing. ( And on that note, here's a quick pitch for the resurrected QualiTI
tool available in xDAIS 6.10, and the new TI eXpress DSP wiki here:
http://tiexpressdsp.com/wiki/index.php?title=QualiTI_XDAIS_Compliance_Tool )
As your signature indicates you're from a University, this may
be an opportunity to share the reasons xDAIS places this restriction on
algorithms with your students, and help them understand why calling malloc/free
are not "good things to do" in an open environment. Here are a few:
* malloc() and free() are often non-deterministic, so
methods calling malloc()/free() lose their determinism
* malloc() can fail(!), what should your algorithm do if
that happens? xDAIS algs restrict failures due to lack of resources to
creation time.
* malloc() and free() don't provide fine-grained _types_ of
memory requests (e.g. internal, external, scratch, persistent, etc) which
complex algorithms typically need.
* and as a result, the use of malloc()/free() hinders
frameworks (like Codec Engine and Framework Components) from sharing scratch
resources across algorithms, which complex systems with many algorithms
typically need.
Chris
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Cheng Yang
Sent: Thursday, March 27, 2008 8:16 PM
To: [email protected]
Subject: Memory operation in the DSP side
Hi, all
I am developping an algorithm for the DSP. In the Codec
Engine framework, the codec is run in the DSP/BIOS. And the codec has to be
complied with the xDAIS standard. So the codec is not allowed to do any memory
alloction operation. It is for the convenience of algorithm users. However, in
our project, we are not going to export the codec to others, which means we
will provide the DSP server directly. So will it be
safe for the codec to do memory operation such as malloc() and free()?
Any discussion will be appreciated!
Best regards!
---------------------
Cheng Yang 杨成
Digital Signal Processing and Transmission Lab
E.E. Department, Fudan University
Shanghai, P.R. China
Lab: +86 (0) 21 65643633
Mobile: +86 13818155051
Email: [EMAIL PROTECTED]
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
