From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mindplay ·
I was wondering if the Synthmaker development team has considered targeting NVidia's CUDA?
Could be pretty sweet, having all that creative power mooching off your graphics card - the price per clockcycle is so much lower on GPUs than it is on CPUs, and you could potentially achieve many times the number of FLOPs you could ever dream of achieving with CPUs.
May not be easy or feasible. But it's an interesting thought, isn't it? 🙂
jobro ·
Only issue I se is that you need a good graphics card to run it.
Nu Audio Science ·
As far as i know you don't gain that much in terms of audio and the last tests undertaken with audio showed that a card that cost roughly $400 performed worse than a complete PC that cost roughly $400 connected using something like FX Teleport or REAmote in Reaper or whatever
The reality was that it didn't just lose out slightly it got whooped upside down and the PC could run close to 4-5 times as much audio DSP
CUDA is great in terms of GFX though and GFX apps can indeed gain massive ammounts of speed ups
NAS
infuzion ·
jobro wrote: Only issue I see is that you need a good graphics card to run it.
I don't think a $40USD card = "good": http://www.nvidia.com/object/cuda_learn_products.html http://www.newegg.com/Product/ProductLi ... gt&x=0&y=0 Although that was good 2 years ago 😀
Nu Audio Science wrote: As far as I know you don't gain that much in terms of audio and the last tests undertaken with audio showed that a card that cost roughly $400 performed worse than a complete PC that cost roughly $400 connected using something like FX Teleport or REAmote in Reaper or whatever
What GPU & what CPU plz? This test says the contray (he may have a newer 8800GTS, so we're talking either an likely
I'm not sure, but isn't the latency for ethernet too much for live? Also some may have a NVidia GPU in their laptop, & want to squeeze out more mobile-studio power without lugging around another computer. -- I don't see CUDA coming to SM, & I don't think there is a public VST using CUDA yet either. I think there are only a few routines from nVidia with basic maths & a few filters right now, & the example above.
Nu Audio Science ·
There was a public VST running CUDA it was available at KVR from one of the devs it was a delay
I bow to your superior and more upto date knowledge infuzion I'm only going on what has been done with VST so far 😉 Perhaps the dev wasn't very good
Ethernet is fast enough to play live easily 😉 Try teleport FX You need giga but that isn't anything special these days
NAS
TomC ·
mindplay wrote: I was wondering if the Synthmaker development team has considered targeting NVidia's CUDA?
Could be pretty sweet, having all that creative power mooching off your graphics card - the price per clockcycle is so much lower on GPUs than it is on CPUs, and you could potentially achieve many times the number of FLOPs you could ever dream of achieving with CPUs.
May not be easy or feasible. But it's an interesting thought, isn't it? 🙂
Interesting? You bet! Making economical sense? No.
It's hard enough to keep things smooth when you develop for Intel+AMD architectures which more or less share the same instruction set. Add support for one or more GPUs and you're in support-hell.
Tom
infuzion ·
Nu Audio Science wrote: There was a public VST running CUDA it was available at KVR from one of the devs it was a delay
Yea I remember the post, but I didn't see a d/l link, do you know where it is? I did find on KVR that Nebula3 will have CUDA support "soon".
Nu Audio Science wrote: I bow to your superior and more upto date knowledge infuzion
I'm thinking of switching to C++/SE & looking for a competitive edge, so I've been watching CUDA for almost a year now.
Ethernet is fast enough to play live easily...You need giga but that isn't anything special these days
Which my new motherboard & laptop don't have 😝 I'm thinking of adding giga will add the latency I'm trying to save?...
infuzion ·
& a bit more on subject, after reading some slides from the CUDA devs/pr, seems CUDA is has single-point float available now, with doubles available "real soon". Also seems that the GPUs don't have "hardware" square root & division like x86 does. A minor drawback, because a drawn-out way of dividing on the GPU is still less math the CPU has to handle 🙂
If you happen to be in/near Germany & have off Monday, you can go to CUDA's (free?) event: http://www.nvidia.com/object/cuda_develop.html
matti ·
Nu Audio Science wrote: There was a public VST running CUDA it was available at KVR from one of the devs it was a delay
It was a public VST and available at KVR but not based on CUDA. A good example of a VST that uses Cuda could be the Nebula.
Cuda is at it's best when it gets multiple tasks to run simultaneously. The test on the link infuzion posted shows a nice 140x speed difference between a cpu and the gpu. Gpu winning ofcourse.. I would call that a significant boost in performance. Running some simple one thread dsp on the other hand might be as slow as on the cpu as the huge parallel processing power can't be used to handle it. Same thing as with the 8core computer processors.
Nu Audio Science ·
Matti it was actually converted to Cuda Maybe that wasn't announced in the thread at KVR Anyway it wasn't very good and i didn't realise Nebula supported it yet I thought it was still in development because there website says to be released Is there website out of date ? Thanks for any info if you have the inside track on that
NAS
infuzion ·
I've been doing more research: Cuda has double-point floats coming out "real soon", divides & another function was "software emulated", denormals are always flush-to-zero, found even faster FFT for CUDA than the CUDA-FFT... ATI has their own version for CUDA, but it doesn't have a following yet it seems. & C++ isn't too hard to learn so far.
Nu Audio Science ·
Cool Keep us informed on your C++ stuff infuzion I will be crossing over soon myself
NAS
Andrew J ·
infuzion wrote: C++ isn't too hard to learn so far.
I've just been starting to look at C++ after having used C# a bit at work lately - and I've got to say it looks ugly! I much prefer ASM 🙂
infuzion ·
Andrew J wrote: infuzion wrote: C++ isn't too hard to learn so far.
I've just been starting to look at C++ after having used C# a bit at work lately - and I've got to say it looks ugly! I much prefer ASM 🙂
Well, Visual C++'s ASM looks very much like SM's, most likely since SM is written in Visual C++ 😉 But SM still seems easier to test ASM snipits, so SM is still HD-keepable IMHO.
exonerate ·
infuzion wrote: Andrew J wrote: infuzion wrote: C++ isn't too hard to learn so far.
I've just been starting to look at C++ after having used C# a bit at work lately - and I've got to say it looks ugly! I much prefer ASM 🙂
Well, Visual C++'s ASM looks very much like SM's, most likely since SM is written in Visual C++ 😉 But SM still seems easier to test ASM snipits, so SM is still HD-keepable IMHO.
I'm developing in both C++ and SM at the moment, in my opinion there perfect partners 🙂 , Learning C++ has helped my SM development, and SM helps with the C++ side.
I plan to do a lot more than just make plugins with C++, but making plugins is proving to be a good way to learn, as I'm already familiar with the concepts involved.
Cheers 😉
Exo
infuzion ·
exonerate wrote: I'm developing in both C++ and SM at the moment, in my opinion there perfect partners 🙂 , Learning C++ has helped my SM development, and SM helps with the C++ side.
Yea, that was my argument for SM having an SDK; to program segments as C++ if I want, & to add limited-audiance things like CUDA...
matti ·
😍 I just tested out using convolution based effects on music production with CUDA and an 8800 GPU. Man that thing is a HUGE number cruncher! A reverb that usually takes around 20% of my dualcore CPU eats less than 1% of the GPU.. I could load up dozens(maybe hundreds?) of them at the same time. That is definetly the the future path for audio processing. Not sure tho how other algorithms will sit on such GPUs, but even if their theoretical maximum speed can't be reached they will still be a good addition to the CPU. Running only convolution/fft stuff on them is also a huge benefit as it's ofcourse a huge reduction to the main CPU load.
Now that those old 8800(or 8600 etc) GPU's are dirt cheap i can see a huge market for VST's utilizing their power 😉
infuzion ·
I think you are still limited by the # of streams the GPU can handle. Also, while GPU for audio seems very tempting there is one problem; there is a sizable delay between the command from the CPU to process to the GPU to actually start processing. 200 cycle delay rings a bell, but you can look for it in some of the CUDA PR info. So, "real-time" GPU is not right now.
But GPU is perfect for mastering, reverb, & anything you don't need right now-now.
matti ·
infuzion wrote: I think you are still limited by the # of streams the GPU can handle. Also, while GPU for audio seems very tempting there is one problem; there is a sizable delay between the command from the CPU to process to the GPU to actually start processing. 200 cycle delay rings a bell, but you can look for it in some of the CUDA PR info. So, "real-time" GPU is not right now.
But GPU is perfect for mastering, reverb, & anything you don't need right now-now.
200cycle? (now that would be very fast) You mean 200 samples perhaps? Even so, it's not big. I currently work with 256 sample latency in my studio. Computer systems are not "real time" anyway. I don't see any problems with the implementation even now. Small latencys can be dealt with.
I'm going to investigate Cuda some more when i get that 8800 card back. There are limitations ofcourse, but i don't think they are that bad. PCI-E 16x is a bit faster than the old PCI right? (soundcards, uad's and powercores are PCI)
aliasant ·
matti wrote: infuzion wrote: I think you are still limited by the # of streams the GPU can handle. Also, while GPU for audio seems very tempting there is one problem; there is a sizable delay between the command from the CPU to process to the GPU to actually start processing. 200 cycle delay rings a bell, but you can look for it in some of the CUDA PR info. So, "real-time" GPU is not right now.
But GPU is perfect for mastering, reverb, & anything you don't need right now-now.
200cycle? (now that would be very fast) You mean 200 samples perhaps? Even so, it's not big. I currently work with 256 sample latency in my studio. Computer systems are not "real time" anyway. I don't see any problems with the implementation even now. Small latencys can be dealt with.
I'm going to investigate Cuda some more when i get that 8800 card back. There are limitations ofcourse, but i don't think they are that bad. PCI-E 16x is a bit faster than the old PCI right? (soundcards, uad's and powercores are PCI)
I have a 8800GT in my computer. Is there any way I (and others ) can test this?
infuzion ·
aliasant wrote: I have a 8800GT in my computer. Is there any way I (and others ) can test this?
I'm not so clear on the delay, but I've read it is noticeable for real-time audio apps... I'd think the best bet for questions like this is the CUDA form: http://forums.nvidia.com/index.php?showforum=62
matti ·
Ah, btw. Until i get my 8800 back i made a little plugin to load IR's to 😉
matti ·
I thought this might be a good place to mention this: Next year there's rumoured to be a new fast platform rivalling CUDA. The Intel Larrabee. Targeting Larrabee is said to be lot easier as it's based on bunch of x86 processors instead of the more "traditional" GPU stream processors. SM should really look into that when it arrives. I sure will 🙂
More about Larrabee: the core has a SIMD Vector processing unit similar to the one used in SSE, except it's width is not 4 floats, it's 16. So as SM now has a 4 voices for the price of one scheme, you could basicly run a 16 voice synth on one Larrabee core(it's said to be an old 1+Ghz Pentium architecture, so it should run one SM-synth easily.. my 600mhz P3 does anyway), and there's said to be up to 32 cores in it. If the instruction set is close enough to SSE it should be a pretty smooth transition...
more stuff at wikipedia
matti ·
Ok, I've now installed CUDA alongside my compiler. First tests were succesfull and a simple convolution app was fairly simple to do. With a bit of research it seems that the GPU can run pretty much any type of algorithms, but with stellar speeds on only the ones that can be properly multi-threaded. So there's no reason for not being able to do even synths on it. What i'm intrested in doing is efficient(and fast) convolution reverbs. The bandwidth of the PCI-E shouldn't be a problem as there only needs to be 256 samples sent and received in a second. So that's 256*4*2 = 2 kibibytes per 1/172th of a second -> 344 KiB per second to and from the GPU. The bandwidth of my GPU is around 2 GiB = 2097152 KiB. Should be enough.. What might be a problem tho is the threading of the VST host program. It might complicate how things can be moved to- and back from the GPU. I need to test things further to see how it goes 🙂
infuzion ·
matti wrote: ...So there's no reason for not being able to do even synths on it. What I'm interested in doing is efficient(and fast) convolution reverbs.
I wonder if synths might be out of the question, since there is a lag between commands/data being sent to the GPU & the GPU executing those commands, much greater than the lag between RAM & CPU. EQs & reverbs seem to be good uses of GPUs though!
matti ·
infuzion wrote: matti wrote: ...So there's no reason for not being able to do even synths on it. What I'm interested in doing is efficient(and fast) convolution reverbs.
I wonder if synths might be out of the question, since there is a lag between commands/data being sent to the GPU & the GPU executing those commands, much greater than the lag between RAM & CPU. EQs & reverbs seem to be good uses of GPUs though!
The lag doesn't seem to be that big. There is a small lag if you read a single value straight from the CPU's RAM on the motherboard, but other than that the system seems pretty fluid and fast. The manual mentions a 400 to 600 cycles of lag when reading from CPU RAM, compared to single cycle of reading from the GPU's low level memory that is shared between threads.. So in that way it is huge, but the GPU runs at over 1000 000 000 cycles per second.. so 400 to 600 cycles ain't that bad. Also, in reality moves to the card are done in batches. So even if memory latency would be higher than on CPU's, the speed thru the PCI-E is not that bad, 2Gib/s on my 8800. Plenty of time for moving simple controller values etc. Creating synth's are definetly possible! You don't need to send anything else to a synth than the notes it needs to play, and some controller values. That's so much less data than what is sent to a convolution reverb.
One cool thing is that you can process on the GPU at the same time when data is moved to and from the card(or do computing on the CPU ofcourse). With this trick the complete memory bandwidth thing can be masked by computing by the values retrieved from a previous pass(if the bandwidth is going to be a problem.. tho it seriously isn't).
I see CUDA as a very promising platform also for audio. I'll let you know when i get my first VST test codes ready 🙂
infuzion ·
matti wrote: I see CUDA as a very promising platform also for audio. I'll let you know when i get my first VST test codes ready 🙂
Wow, lots of great info & insight; thanks Matti! CUDA (& lack of SDK) is making it very tempting for me to dump SM in the next few months...
matti ·
infuzion wrote: matti wrote: I see CUDA as a very promising platform also for audio. I'll let you know when i get my first VST test codes ready 🙂
Wow, lots of great info & insight; thanks Matti! CUDA (& lack of SDK) is making it very tempting for me to dump SM in the next few months...
Well there's no reason to dump SM for that.. I'm for example protyping the fft convolution engine first inside SM. It's pretty much fully functional now, except a bit slowish.. Next step is to write it to C++/Cuda and run benchmarks. It's lot more fun building something with SM, so i'm definetly not leaving it 🙂
matti ·
matti wrote: Well there's no reason to dump SM for that.. I'm for example protyping the fft convolution engine first inside SM. It's pretty much fully functional now, except a bit slowish..
Ha.. now that i mentioned it i ran into some trouble. I'm getting a few calculation errors from propably the fft's. Where ever it's coming from it builds up into the quiet parts and nulls everything from it's path. Other than that my partitioned overlap-save convolution algorithm seems to be working.. tho it takes 2 seconds to calculate a 1.5 second verb for 256 samples. SM might not be that efficient for this type of thing.. I would need to slim it down to just few ms in CUDA. I just tested that the data transfers needed for a vst-effect take under 0.5ms so that doesn't seem like a problem yet.
rl ·
just curious: how did you implement the prototype e.g. the nested loops of typical FFT? assembly?
matti ·
rl wrote: just curious: how did you implement the prototype e.g. the nested loops of typical FFT? assembly?
I didn't build my own fft. I used the SM's one. And in cuda I'm using the included cufft library, which is based on fftw (sm's fft is maybe fftw too?).
matti ·
If anyones intrested... I finally had some time to do tests with the CUDA convolution kernel i'm working on. The figures from a test i ran look promising, except for the part of retreiving the data back from the card:
block size: 256 memory move time: 0.016909 (ms) FFT processing time: 0.069471 (ms) complex multiply: 0.023685 (ms) (0.021075 ms even with a bigger 177152 block size) iFFT processing time: 0.061804 (ms) move data back: 1.78119 (ms)
I tried to simulate a situation where i would have a 256 sample block size(the latency i currently use in studio myself) and would need to move only that amount of data back and forth during every block. I have no idea how VST's internally work concerning the latency times, and if the times presented here will be enough for it to work, but i'm going to try it anyway 🙂
With bigger blocksizes the memory moves increase linearly, and when building in debug mode all kernels seem to freeze up (the time they take to run increases almost 100x), so if you are evaluating the CUDA platform for some project remember those.
The tests were done on a 2,8GHz PentiumD with a 96 core 8800GTS card(G80) and the CUDA 2.0.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker