On Tue, Aug 11, 2009 at 06:50:50PM +0200, Jens M Andreasen wrote: > That would be four warps > independently working their way through the variously sized sample > blocks, each thread execting serial code that looks very much the same > as jconv itself, including the threading.
Note that the algorithm implemented by libzita-convolver (used by jconv) when used in real-time mode relies on regular scheduling (i.e. being called from a Jack process callback) and carefully set thread priorities. How to structure a convolution engine to run on a graphics processor would very much depend on where you want the I/O. If it remains a Jack app then the easiest way would be to offload the work done for the larger partition size(s) to the graphics processor. Timing is absolutely not critical in that case, but if more than one partition size is moved in that way, or if you have more than one instance running you'd still need to respect relative priorities. Now jconv is a general purpose tool designed to efficiently handle any convolution matrix, including sparse ones. If you use it for reverb the matrix size is small (usually 1x2 or 2x2 for stereo). An application that runs e.g. 8 of those can be structured in a completely different way that could avoid the use of multiple priorities. > How much jconv would something like a 300Mhz Pentium Pro buy me? (Just > to get a hunch if this would be a possibility at all) Almost impossible to tell without trying. It also depends in a very complex way of the configuration - the ratios will not be the same on all machines. Jconv's predecessor, jace, worked by trying to distribute the work done on large FFTs and MACs as evenly as possible over callbacks with a shorter period. A condition for doing this is of course that you can estimate the work to be done in the first place. It was the impossibility of doing this for the more general use cases that jconv is supposed to handle that forced me to adopt the multi-threaded/multi- priority solution. Ciao, -- FA Io lo dico sempre: l'Italia รจ troppo stretta e lunga. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
