12 Oct
2010
12 Oct
'10
4:29 p.m.
Message: 9
Date: Mon, 04 Oct 2010 13:51:07 +0200
From: Max Tandetzky <max.tandetzky(a)uni-jena.de>
Subject: [LAD] CUDA implementation for calf
To: linux-audio-dev(a)lists.linuxaudio.org
Message-ID: <4CA9BFAB.2090707(a)uni-jena.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hallo,
I am new here, so I hope this is the right place to talk about what I
want to do.
I want to make a CUDA implementation of the algorithms from the
calf-plugins. On the front end there should be placed a button (or
something else) to (de-)activate the CUDA support. I have already
written a jack-program (which makes some simple changes on audio data)
using CUDA. It works good and at a first sight the performance looks
promisingly.
I have read a part of the mailing list archive and found out that there
already was a discussion about audio processing with CUDA. I know there
are some reasons for not using CUDA like the duty to use the proprietary
Nvida driver, the limitation that only people who have an Nvidia card
will have a benefit and so on. But the CUDA implementation may show
which performance can be reached and may beuseful for Nvidia users
immediately.
I know there is OpenCL but it is not as sophisticated as CUDA at the
moment, will have less performance than CUDA and I do not have the time
to learn OpenCl at the moment (but the project has to be finished soon).
I heard it is not too much work to transfer existing CUDA code to OpenCl
code later (assuming there is already an OpenCL implementation for all
CUDA functions which were used).
So I want to do this with CUDA.
At the moment I have some questions:
1. Is there anybody has already done or is doing something like this?
2. Where can I get information to make any specific changes on the calf
code? (I examined it a bit but it will take time to understand the
structure of the program when I only have the code, especially the part
for the GUI seems to be conceptualized a bit more complex.)
It would be nice if I can get some help here.
Regards
Max Tandetzky
Hi Max,
I've done some test using OpenCL in the context of the Faust project
(http://faust.grame.fr/). Up to now results are not really good, and I guess CUDA/OpenCL
will be usable only in specific cases. I'll probably now test if directly using CUDA
would give some benefit. Maybe we can share some ideas?
Stéphane
12 Oct
12 Oct
8:12 p.m.
New subject: Linux-audio-dev Digest, Vol 44, Issue 6
On Tue, 2010-10-12 at 16:29 +0200, Stéphane Letz wrote:
>
I've done some test using OpenCL in the context of
the Faust project
(http://faust.grame.fr/). Up to now results are not really good, and I
guess CUDA/OpenCL will be usable only in specific cases.
What kinds of parallellism have you been exploring?
I have found that the multiple channel strip approach with mixdown to
subgroups is straight-forward for a DAW, as well as for polysynths.
Global sync points between multiprocessors - for cascaded processing -
works up to a limit after which the squared cost of the sync eats up the
computational value of the added multiprocessor. I am syncing the 6 MP's
on a GT220 every 16 samples at 96kHz with a penalty in the 5% range. On
higher end cards this approach is not very useful though. Discouraged by
Nvidia staffers also ...
In theory, the granularity of the vector needs to be no higher than 32
vector elements to be efficient - that is how the hardware
multithreading works. In practice, for the given use case, you will find
yourself trashing the instruction cache if you use too many divergent
warps. Two, perhaps three, completely different code paths on each MP
works well.
192 or 256 threads are a minimum to hide instruction latency, leading to
the conclusion that the effective vector as seen by the outside world
needs to be at most 128 elements wide (256/2, which is what I currently
use) and possibly as low as 64 (192 threads / 3 codepaths)
I'll probably now test if directly using CUDA
would give some benefit.
Maybe we can share some ideas?
CUDA is nice :)
Stéphane
/j
--
jedes mal wenn du eine quintparallele verwendest
tötet bach ein kätzchen.
http://www.youtube.com/watch?v=43RdmmNaGfQ
8:30 p.m.
New subject: Linux-audio-dev Digest, Vol 44, Issue 6
Le 12 oct. 2010 à 20:11, Jens M Andreasen a écrit :
So I'll try.
Thanks
Stéphane
On Tue, 2010-10-12 at 16:29 +0200, Stéphane Letz wrote:
Well, Faust is able to generate a DAG of separated loops, some of them are data
parallelizable, others are not (recursive).
Right now I'm testing a simple strategy where the DAG is reduced as a sequence of
"group of parallel loops" slices. Sync points are added between slices.
Data paralelizable loops are not yet correctly handled, which has to be done obviously. So
the current model is basically tasks parallellism and is quite naive...
>
I've done some test using OpenCL in the
context of the Faust project
(http://faust.grame.fr/). Up to now results are not really good, and I
guess CUDA/OpenCL will be usable only in specific cases.
What kinds of parallellism have you been exploring?
I have found that the multiple channel strip approach with mixdown to
subgroups is straight-forward for a DAW, as well as for polysynths.
Global sync points between multiprocessors - for cascaded processing -
works up to a limit after which the squared cost of the sync eats up the
computational value of the added multiprocessor. I am syncing the 6 MP's
on a GT220 every 16 samples at 96kHz with a penalty in the 5% range. On
higher end cards this approach is not very useful though. Discouraged by
Nvidia staffers also ...
In theory, the granularity of the vector needs to be no higher than 32
vector elements to be efficient - that is how the hardware
multithreading works. In practice, for the given use case, you will find
yourself trashing the instruction cache if you use too many divergent
warps. Two, perhaps three, completely different code paths on each MP
works well.
192 or 256 threads are a minimum to hide instruction latency, leading to
the conclusion that the effective vector as seen by the outside world
needs to be at most 128 elements wide (256/2, which is what I currently
use) and possibly as low as 64 (192 threads / 3 codepaths)
Well you obviously have a lot of practical knowledge I don't have. Any code samples
you could share?
I'll probably now test if directly using CUDA
would give some benefit.
Maybe we can share some ideas?
CUDA is nice :)
10:11 p.m.
New subject: Linux-audio-dev Digest, Vol 44, Issue 6
On Tue, 2010-10-12 at 20:30 +0200, Stéphane Letz wrote:
Well you obviously have a lot of practical knowledge I don't have. Any
code samples you could share?
>
Examples of what?
I don't know where you are heading nor what kind of hardware you are
considering - and specifically I do not believe the single plugin
philosophy to be useful at all on the GPU... If that is where you wanted
to go.
BTW: Have you read the CUDA Programming Guide yet?
--
jedes mal wenn du eine quintparallele verwendest
tötet bach ein kätzchen.
http://www.youtube.com/watch?v=43RdmmNaGfQ
13 Oct
13 Oct
7:09 a.m.
New subject: Linux-audio-dev Digest, Vol 44, Issue 6
Le 12 oct. 2010 à 22:10, Jens M Andreasen a écrit :
On Tue, 2010-10-12 at 20:30 +0200, Stéphane Letz wrote:
Example of CUDA used for audio.
Well you obviously have a lot of practical knowledge I don't have. Any
code samples you could share?
>
Examples of what?
I don't know where you are heading nor what kind of hardware you are
considering - and specifically I do not believe the single plugin
philosophy to be useful at all on the GPU... If that is where you wanted
to go.
The point for us is to find if a general DSP programming language like Faust can take
benefit of a CUDA/OpenCL backend, to be used obviously for heavy algorithms that show
massive data et task parallelism.
BTW: Have you read the CUDA Programming Guide yet?
Started yes.
Thanks
Stéphane
8:28 a.m.
New subject: Linux-audio-dev Digest, Vol 44, Issue 6
On Wed, 2010-10-13 at 07:09 +0200, Stéphane Letz wrote:
If we for now ignore getting data in and out - which I understand you
are reading up upon now - there are two main use cases:
a) Vertical signal flow: The signal flows from the top of each thread,
starting at a location in shared memory chosen by indexing and ends up
in another, fixed and known location, also in shared memory. Shared
memory works like a switchboard with 4096 plugs, where any output can be
the input of any other. In this case the code is identical to what
you'll find in textbooks or floating around in DSP forums, including
this one. The difference being that you'll get 128 instances of each
functionality rather than just one.
b) Horisontal signal flow: The above approach does not work for things
like say delaylines (longer than a few samples) where you want each
instance to have their delaytime individually parameterized. In this
case you will therefore first transform the outputs so that a collection
of vertical signals like:
a A 1 $ a b c d..
b B 2 # A B C D..
c C 3 ! becomes horisontal: 1 2 3 4..
d D 4 ? $ # ! ?..
: : : :
You will want to do this in chunks of 16 elements because this is how
the memory controller works. A codepath driving 128 threads can then
adress 8 unrelated global memory locations in parallel to store as well
as load the right chunks(s) back into shared memory - after which the
individual threads can look left and right for finetuning, interpolation
and/or FIR filtering.
--
eins, zwei, drei ... tekno tekno??
http://www.youtube.com/watch?v=ZEgbW1FxR78
Examples of
what?
Example of CUDA used for audio. 
14 Oct
14 Oct
5:38 p.m.
New subject: Linux-audio-dev Digest, Vol 44, Issue 6
On Tue, Oct 12, 2010 at 10:09 PM, Stéphane Letz <letz(a)grame.fr> wrote:
Example of CUDA used for audio.
):
GPU processing for sound via CUDA has already been done a little bit
in the windows/mac world:
http://www.acusticaudio.net/modules.php?name=Products&file=nebula3
http://www.kvraudio.com/forum/viewtopic.php?t=222978
http://www.kvraudio.com/forum/viewtopic.php?t=240824
http://www.nvidia.com/content/GTC/posters/2010/C01-Exploring-Recognition-Ne…
C01 - Exploring Recognition Network Representations for Efficient
Speech Inference on the GPU
We explore two contending recognition network representations for
speech inference engines: the linear lexical model (LLM) and the
weighted finite state transducer (WFST) on NVIDIA GTX285 and GTX480
GPUs. We demonstrate that while an inference engine using the simpler
LLM representation evaluates 22x more transitions per second than the
advanced WFST representation, the simple structure of the LLM
representation allows 4.7-6.4x faster evaluation and 53-65x faster
operands gathering for each state transition. We illustrate that the
performance of a speech inference engine based on the LLM
representation is competitive with the WFST representation on highly
parallel GPUs.
Author: Jike Chong (Parasians, LLC)
http://www.nvidia.com/content/GTC/posters/2010/C02-Efficient-Automatic-Spee…
C02 - Efficient Automatic Speech Recognition on the GPU
Automatic speech recognition (ASR) technology is emerging as a
critical component in data analytics for a wealth of media data being
generated everyday. ASR-based applications contain fine-grained
concurrency that has great potential to be exploited on the GPU.
However, the state-of-art ASR algorithm involves a highly parallel
graph traversal on an irregular graph with millions of states and
arcs, making efficient parallel implementations highly challenging. We
present four generalizable techniques including: dynamic data-gather
buffer, find-unique, lock-free data structures using atomics, and
hybrid global/local task queues. When used together, these techniques
can effectively resolve ASR implementation challenges on an NVIDIA
GPU.
Author: Jike Chong (Parasians, LLC)
-- Niels
http://nielsmayer.com
4945
days inactive
4947
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Jens M Andreasen -
Niels Mayer -
Stéphane Letz