On Tue, Aug 11, 2009 at 08:56:56PM +0200, Jens M Andreasen wrote:
> Say warp A (or "process" A) must do four smaller workloads while warp B
It's not that simple...
An example: the santalucia reverb with period size = 256,
mininum partition size = 256.
There will be 3 partitions of 256 frames, 6 of 512, 6 of 2048
and 24 of 8192 frames.
The first will be done in jack's callback and the others at
lower priorities, resp. -1,-2,-3 relative to jack's thread (*).
Each of these threads is triggered into action with a period
equal to its partition size, and the work is expected to be
ready at the next trigger.
That means that the thread that does the size 512 ones must
have priority over all the others. Except in some simple
cases it's almost impossible to divide the work done by e.g.
the slowest thread into equal parts. If that were possible we
wouldn't need multiple threads at all - the evenly divided
workload could be done in jack's callback without problem.
As things are, pre-emption seems to be the only solution.
> I found a measure of ~1 sec for a 128K FFT on a PPro @200
No. The largest FFT used by jconv is 16k, it doesn't pay to
increase that size. Depending on the configuration the FFTs
could dominate the workload (many short 1-to-1 convolutions)
or the MAC operartions would take most of the time (long IRs
and/or a dense matrix). And then there's the cache size that
will have all sorts of complicated effects.
(*) From the next release that would be -1,-3,-5, i.e. one
less for each doubling of the size. This allows multiple
jconvs to be scheduled fairly even it they don't use the
same set of sizes. Other apps doing similar things should
use the same system if they are supposed to work together
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Linux-audio-dev mailing list