New hardware?

[TweakHead]

Originally Posted by MBTC

It is promising to see these reverb plug-ins making progress in their development. Reverb is a really CPU-gobbling and commonly used effect.. in fact probably if there was one I would identify to offload to a secondary processing mechanism, that would be the one.

Yes, but why stop there? If we take a look at Universal Audio's offers, some of them are quite demanding as well. Simply because they can afford the luxury of using more complex code in their products that would otherwise be a nightmare to use for mixing purposes. Actually, I wonder why Universal Audio hasn't put out some synthesizers yet. But maybe they will if they pay attention to the market. I mean, most people these days are demanding more and more quality in their instruments. That's the sole reason analogue has returned - quality and interaction with the instrument of course. And all of that without making the cpu ask for mercy.

[MBTC]

Originally Posted by TweakHead

Yes, but why stop there? If we take a look at Universal Audio's offers, some of them are quite demanding as well. Simply because they can afford the luxury of using more complex code in their products that would otherwise be a nightmare to use for mixing purposes. Actually, I wonder why Universal Audio hasn't put out some synthesizers yet. But maybe they will if they pay attention to the market. I mean, most people these days are demanding more and more quality in their instruments. That's the sole reason analogue has returned - quality and interaction with the instrument of course. And all of that without making the cpu ask for mercy.

I wondered about this as well. When something like the quad-core Apollo interface costs something like $3000 with the thunderbolt card, why not go ahead and turn it into a full-fledged instrument with synth plug-ins that run on it? Maybe they are headed in that direction. I guess they figured all the really good synth developers are already self-employed and creating their own VSTs, and that hiring someone mediocre to develop a synth just to say they have one in their product line up isn't going to result in top-notch brand recognition. Its only a theory but one possibility.

I've been thinking more about why nobody has made a more firm commitment/organization investment to audio on CUDA, and again I've come up with a possibility that would give me pause as a developer. It doesn't mean it's THE reason, it's just one that could be a showstopper: Basically if I, as a developer decide to invest heavily in CUDA (let's say I invest enough man hours learning their SDK, then developing a synth), I might end up spending something like 1000 man-hours, either my own labor or contracted out, to do so. That's a major investment of time, money or both. Nvidia drivers of course are always evolving, and getting updated. They do backward compatibility testing for games every time they do a driver update, but what's to say they are going to add my synth to the list of apps to test for backward compatibility when they do a new driver release? Probably not much at the current stage, because they are in the graphics business rather than the music business. For the type of investment it would take to develop the synth, I would need some level of assurance that they are not going to blow my synth out of the water with a single driver update, and honestly right now they are probably not going to be able to provide that to a synth company. Maybe a larger company could form some sort of partnership with them and get it done, but it would be a very risky move for a small developer to invest so much only to have their eggs in one basket.

The good thing about dedicated audio hardware is that if you've got a stable setup, there's usually nothing pressing that says you must install every update for every piece of software as it comes out, and there's really nothing about the standard automatic Windows or OSX updates that is going to make core changes to the way audio is handled at the kernel level, or something else that could affect code at a higher layer up like the VST API. That's the beauty of the VST API, it is designed for audio technology, thus very conducive to creating synths. From what I hear about CUDA, not so much in its current form. Also, most people will update their graphics drivers regularly just as a matter of maintenance, and would not think about the possible impact to their music setup of updating a newer driver, then having all their synths go tits up or whatever.

[TweakHead]

You're probably right. Nvidia is pushing for better gaming performance above everything else. I think this CUDA thing is also some form of publicity: they're glad that some scientists find other uses for their powerful hardware and all of that, but they're certainly not making efforts to make their day. The same goes to audio applications. But what about Open CL? I know that's some kind of standard for such things, isn't it? I remember Steve Jobs making a big deal out of it when it was introduced to Mac OS, and thinking: what happened to this revolution? How come I never saw it being used?

OpenCL 1.0 has been released with Mac OS X Snow Leopard. According to an Apple press release:[6]

Snow Leopard further extends support for modern hardware with Open Computing Language (OpenCL), which lets any application tap into the vast gigaflops of GPU computing power previously available only to graphics applications. OpenCL is based on the C programming language and has been proposed as an open standard.

Same story we're talking about here. The technology seems to be there and we certainly have more power in our machines then ever before, but the industry has interests of its own and it's very hard to come to terms and create standards or give developers the kind of assurance you mentioned. I feel that's the case for almost everything.

[MBTC]

Actually, much more is happening with CUDA beyond just gaming applications. Most folks are only familiar with the GeForce line of products, but check out the Tesla line of cards, for example:

http://www.nvidia.com/object/tesla-s...solutions.html

However, some of their Tesla-line cards cost thousands of dollars. Sometimes you look at one of their scientific-use cards and wonder why, if the paper specs are the same, they cost so much more than the consumer gaming card that uses mostly the same internals?

Part of that comes down to things I alluded to before, like backward compatibility with regard to what its used for. The GeForce line allows them to focus on gamers, and only be concerned with driver compatibility for games. With the Tesla line they can optimize for scientific uses and such, without worrying about goals for the gaming market.

For example, if you've ever looked at a big PC maker like Dell or HP, they typically have their website divided up into consumer and business models. If you look at the technical specs, a given consumer laptop that costs $1500 might be the equivalent of a similar business model laptop that costs $2500 or more. What's the difference? Why wouldn't a business just buy the cheaper consumer version?

Most of that comes down to availability of parts. If you're a large corporation ordering 500 of those laptops, you want to be damn sure that if you need to replace parts a couple of years down the road, that those parts are still available quickly (i.e. overnight shipment) from the manufacturer. Its critical when you have that many assets of the same type in the field. So, with the business-grade models you are guaranteed a certain level of part availability. Consumer models are meant to be sold onesy-twosey and there's no guarantee the consumer can get a replacement part quickly direct from manufacturer past the 1 year warranty, or if there is, it is supplemented with extra warranty cost and wait times.

It might seem we're drifting far from music related discussion here, but the concepts are the same with regard to CUDA. It's definitely a real technology that has valid uses, it's just that the scientific uses are niche enough that they need to pay a premium for same hardware, the primary difference being drivers that are optimized for their use instead of gaming. This would all be fine for audio, except that it would be a hard sell to a synth lover that they need to spend $3k-6k on a GPU to use it as an auxiliary synth or FX processor, the value starts to decline. The real value is in using the GPU that folks already have and I can see some hurdles to that.

[feedingear]

Originally Posted by MBTC

Try the reverb download Tweak posted. I'm going to try it soon, possibly this weekend. I remember it crashing on me a few years ago with an error, but its been patched many times since then and that was inside FLStudio, a DAW that not everyone tests their plugs-in for.

I'll have a look see - gotta admit im pretty happy with QL Spaces atm for simple convolution verbs. And now at work I am learning to use this - and god damn it sounds good...

http://www.bricasti.com/m7.html

[Berni]

Originally Posted by feedingear

I'll have a look see - gotta admit im pretty happy with QL Spaces atm for simple convolution verbs. And now at work I am learning to use this - and god damn it sounds good...

http://www.bricasti.com/m7.html

Jeez I hope so, those things don't come cheap! Totally jealous!

[plaid_emu]

From EvilDragon at the Gearslutz forum:

Originally Posted by EvilDragon

Hell, can someone please post there on Virus forums that the main reason CUDA is under-utilized in audio processing is its incurred processing and data transfer latency? It's simply a different kind of CPU and doesn't scale well for all kinds of math operations. Not everything can be perfectly parallelized in audio DSP. Urs could say a thing or two about this. heh

I don't want to register there (not owning a Virus either) just to say that. Thanks.

[MBTC]

I can fully believe not all audio applications lend themselves to parallelism, but considering the amount of polygon rendering that can be passed between multiple GPU threads with insanely low latency, I have to believe there are at least some audio applications that could be handled very effectively using CUDA.

Thanks for posting his message for him, but if he can't be bothered to register (I don't own a Virus at the moment either, BTW), then I'd say there's not much value in a drive-by post like that unless he wants to stick around and discuss exactly what is different about them, and what kind of math needs to be done in audio that GPUs are not good at. I would certainly listen.

[EvilDragon]

So alright, I registered. Hello!


Yes, CUDA is great for highly parallel operations. Convolution will lend itself great to this, that's why one of first audio uses of CUDA (or, better said, GPGPU - we have OpenCL as well) was precisely convolution. There are things which won't work as well, because they depend on linearly executed algorithms - like delays, algorithmic reverbs, lookahead compressors/limiters and most filter designs. Why? Because they depend on previously calculated samples, and with this high level of parallelism that we have in GPGPUs, there is a problem of returning values consistently in time, which is highly relevant for linear operations.

So, this means that you cannot simply port the whole synth structure to a GPU, because things depend on each other - oscillators precede mixers which precede filters etc. This is what would actually cause greater latency than when using a regular CPU which has special registers to help with fast calculation of certain operations (MMX, SSE, AltiVec, etc.). And that is why GPGPU is not yet used for offloading whole synth architectures from the main CPU.

Now, SOME things can be offloaded to them, and when they are done well, it's a splendid thing. For example, the analytic zero-feedback delay filter calculation that's done in u-he Diva could be parallelized on a GPU to great extent - but this is not yet in u-he's plans.

There is also a problem with compatibility and lack of proper standard: we have CUDA, OpenCL and Microsoft's Direct Compute. As if it's not enough to support VST, AU, RTAS and AAX?

[MBTC]

Hi, welcome, and thanks for registering

The problem of returning values with consistent timng is one that GPU developers are fairly accustomed to dealing with I think.... recently there has been somewhat of a spotlight on frame time variance and latency with regard to rendering complex 3D scenes on multiple GPUs.

What's odd about mentioning MMX and SSE for example, as features of a CPU that exclude doing same on a GPU, is that these extensions were originally created to do 3D graphics type operations; something seems at odds there.

I've never developed using CUDA, so to some extent my guesses here are admittedly uneducated, but even given the understanding that some algorithms are simply serial in nature, I still don't see why each oscillator couldn't have its own thread, reverb1 has its own thread, reverb2 has its own, and so on. One of the big selling points of the DSP in the Virus is specialized parallel filter processers, so lets say those are paralleled on the GPU or worst case scenario each filter and envelop gets their own thread.

In other words, to the best of my knowledge most plugins on the CPU today are not achieving more efficient use of multi-core CPUs by using parallelism to solve math problems that are serial in nature, they are simply using additional threads to divvy up the workload of separate features.

I hear ya on the lack of proper standard, although my original thought on CUDA is really the same as the old Virus plugin on TCE Powercore cards... that was certainly not a standard, but a proprietary solution dependent on owning that card. The difference I see with NVidia is that an insane number of people already have these in their systems, going unused for the most part while making music.