KVR Audio

cYrus · Post by **cYrus** » Mon Oct 09, 2006 11:15 am

well, i don't see any problems with the fast moving graphiccards business. almost everything is abstracted through the directx layer.. and the pixelshader code will be backward compatible for many years..

Nils Schneider · Post by **Nils Schneider** » Mon Oct 09, 2006 11:21 am

Exactly, I don't see any reason of not doing it.

And for comparison just take a look at UAD or PoCo, the problems of finding boards with enough PCI slots are already starting. So who cares? For me, it's still: FUN doing it!

@Aleksey: Most of the problems that you mention are problems that the programmers might have, not the customers. So you can't count them imho, it depends on the programmer if he is willing to do it or not. If the customer receives a reliable product, everything is fine.

Aleksey Vaneev · Post by **Aleksey Vaneev** » Mon Oct 09, 2006 11:37 am

Nils Schneider wrote:Sorry, but everyone that thinks it's easy to run a UAD plug, PoCo plug or GPU plug on an native CPU just by a simple switch: this is WRONG!

Not as much as you think. The most practical flow of development would be creating prototype using the most convenient tool: higher level language like C, because you can test various processing algorithms (like parallel computing) easily there. Developing and testing algorithms on embedded system is much more problematic. It is like writing and developing complex DSP algorithm using assembler code alone: a hard task if you ask me.

Nils Schneider wrote:@Aleksey: Most of the problems that you mention are problems that the programmers might have, not the customers. So you can't count them imho, it depends on the programmer if he is willing to do it or not. If the customer receives a reliable product, everything is fine.

You are right, this is developer's problem. But it will become customer's one as well, if developer won't be able to deliver updates/features that customers are willing to get. (beside that you've skipped problem of processing latency, and customer's costs on wasted CPU power)

Moreover, I as a small independent developer, do not see a way to justify expesive ways of developing plug-ins: everything is possible, but one should ask about cost of such development.

You are good for doing this gpuDelay and gpuChorus development for free. But do not get me wrong: in the long run this means too little since you alone won't please a vast world of pro audio.

Beside that, before I seriously start to consider GPU plug-in development, somebody have to prove GPU plug-ins work absolutely seamlessly on end user's system. It seems that they do not, from your attempt (and my private attempt as well).

jens · Post by **jens** » Mon Oct 09, 2006 1:15 pm

Aleksey Vaneev wrote:
In fact I'm feeling a bit unlucky since the developer which I gave this job to (year back from now) was not able to deliver a good working application. It seems that gpuDelay by Nils works a lot better.

that's a real bummer!

munchkin · Post by **munchkin** » Mon Oct 09, 2006 4:24 pm

Aleksey Vaneev wrote:Beside that, before I seriously start to consider GPU plug-in development, somebody have to prove GPU plug-ins work absolutely seamlessly on end user's system. It seems that they do not, from your attempt (and my private attempt as well).

I don't understand your reluctance. The delay is working seamlessly on my system. The only reason I can't run the chorus is because my card is PS2 not PS2.0b.

As this is pioneering work then there will be risks involved. Imagine if Edison gave up after the 1000th attempt. I'm not seriously comparing GPU plugin development to the fundamental discoveries of Edison but the spirit of that endeavour, the inquisitiveness and tenacity, are needed to make GPU plugins work. Perhaps that's what Nils has got while you have more at stake developing your native plugins.

Synesthesiac · Post by **Synesthesiac** » Mon Oct 09, 2006 5:14 pm

well, edison was a thief and a bully (google Nikola Tesla) but i agree with you.

congratulations Nils Schneider for a great accomplishment!! lots of people waited so long for this.

one concern i have: the only thing keeping me from wasting even more time playing games is my old crappy Matrox G400. if i upgrade, my willpower will be powerfully tested.

Aleksey Vaneev · Post by **Aleksey Vaneev** » Mon Oct 09, 2006 7:04 pm

munchkin wrote:
Aleksey Vaneev wrote:I don't understand your reluctance. The delay is working seamlessly on my system. The only reason I can't run the chorus is because my card is PS2 not PS2.0b.

As this is pioneering work then there will be risks involved. Imagine if Edison gave up after the 1000th attempt.

My personal test show that gpuDelay works unacceptably, stability-wise. I get constant CPU spikes with gpuDelay at least.

On your Edison note, I should say that I'm at no power to fix GPU problems. For example, it is obvious that Nils made all the best he could... But things do not work as they should still. So, even if you are Einstein it won't work.

zeep · Post by **zeep** » Mon Oct 09, 2006 7:15 pm

I replied <10 pages and haven't read everything since then. Is the plugin still in testing phase? (if at all in production)

ddummer · Post by **ddummer** » Mon Oct 09, 2006 7:21 pm

Aleksey wrote:

For example, it is obvious that Nils made all the best he could... But things do not work as they should still.

Negative?
Impatient?

//Daniel

Nils Schneider · Post by **Nils Schneider** » Mon Oct 09, 2006 7:35 pm

Some comments from me to the idea to create a GPU host etc...

As some of you may have already noticed, if the same plugin is uses multiple times, the startup is faster. That is caused by the VST plugin concept. The same renderer is used for multiple plugins, which is working well.

As you may've noticed too is that different plugins (delay+chorus) won't work at all at the moment. This is because the renderer isn't shared across different plugins. But this will have been fixed in the next release, maybe tomorrow evening. So all plugins will only use one rendering engine, resulting in something like a "GPU Host". Saving both memory and startup performance for every plugin after the first one.

The powercore "driver" is working in a similar way. But don't mix this up with collected transfer to the DSP and back from the DSP to the system memory. This won't work because it can't be clearly defined when one processing "frame" starts and ends. Also the order isn't clear, one plugin may depend on the already processed data of another plugin running on the same "DSP" (or GPU). The only argument for such a thing would be to better usage of the parallelism of the GPU architecture, but because buffer sizes are always greater than the number of available pixel units (24 units on e.g. a Geforce 7900) this is no problem and won't make a big difference.

The powercore drivers also have the job to do to spread plugins across multiple DSPs. But this works only when knowing how much power in percent a plugin will use. Because GPUs are generalized and different from card to card, this won't work at all. Instead, if your GPU is at it's end of processing power or the bandwidth to transfer data back from your graphics card to the system memory is busy, it'll be noticed by crackling just like as when plugins are computed on the CPU.

At the moment, my profilings (for non-programmers: analyzing which parts of the source code cost most CPU) prove me right of what I'm doing because what costs most at the moment is the wait for the transfer back from the GPU to system memory on an AGP system, which should hardly be noticed on PCIe-Systems, which will give the capability to use lots of instances of different plugins and save a lot of CPU.

Everyone that means that it can't ever be stable enough: I don't force people to use it. I'm doing this in my spare time mainly for myself to be able to have a little bit more power beneath my two Powercores and because I just like programming this. Everyone that likes it is free to use it, everyone that doesn't, no problem. But of course I'm always open for discussions about it. But if it is usable should everyone define for himself.

_niko_ · Post by **_niko_** » Mon Oct 09, 2006 7:47 pm

Dear Aleksey,
I can totally understand, that you don't want to get involved into this for various, understandable reasons as you have made clear now several times. What I don't really get, is why you still continue to post to this thread, all the time emphasizing the possible problems and negative side of things.
What Nils released here so far, as I see it, are two proof of concept plugins, that are obviously not yet working problem-free everywhere, but still show the potential of using the GPU for audio processing. That alone is quite an achievement, in my book, and he deserves praise for it. Seemingly, there are quite a few people around here, that are interested in this new approach, so why not give things a chance to evolve?
Don't get me wrong, no disrepect meant whatsoever, I am a registered user of a couple of Voxengo plugins that I really like!

oblagon · Post by **oblagon** » Mon Oct 09, 2006 7:49 pm

todd_r wrote:Farlight have just released a new system (cc-1) that wipes the floor with pro-tools powerwise, and they are offering the technology to other manufacturers to develop on, they should whack their plugs onto one of these buggers

http://www.fairlightau.com/default_content.html

This suppose to be VST compatible

Aleksey Vaneev · Post by **Aleksey Vaneev** » Mon Oct 09, 2006 7:54 pm

_niko_ wrote:What I don't really get, is why you still continue to post to this thread, all the time emphasizing the possible problems and negative side of things.

I'm doing this with only one hope: to receive GOOD arguments against my seeming 'whining'. Because, as I've said, I too would like to use GPU in one plug-in or another, if it works as intended.

munchkin · Post by **munchkin** » Mon Oct 09, 2006 7:58 pm

Aleksey Vaneev wrote:
munchkin wrote:
Aleksey Vaneev wrote:I don't understand your reluctance. The delay is working seamlessly on my system. The only reason I can't run the chorus is because my card is PS2 not PS2.0b.

As this is pioneering work then there will be risks involved. Imagine if Edison gave up after the 1000th attempt.
My personal test show that gpuDelay works unacceptably, stability-wise. I get constant CPU spikes with gpuDelay at least.

On your Edison note, I should say that I'm at no power to fix GPU problems. For example, it is obvious that Nils made all the best he could... But things do not work as they should still. So, even if you are Einstein it won't work.

Not everyone is having the problems you describe. I'm not getting the cpu spikes you report.

I've bought a lot of native plugins and during the development stage there have been all sorts of problems including cpu spikes. This isn't unusual during beta stage is it?

Aleksey Vaneev · Post by **Aleksey Vaneev** » Mon Oct 09, 2006 8:04 pm

Nils Schneider, do not get me wrong, but if your 'gpuhost' is located in the same process (i.e. DLL loaded in audio host process), all resources will be shared between this 'gpuhost' and audio host application. This is just how Windows works. To be fully separated from audio host's resources you'll have to start another process, and use inter-process communication.

This won't work because it can't be clearly defined when one processing "frame" starts and ends. Also the order isn't clear, one plugin may depend on the already processed data of another plugin running on the same "DSP" (or GPU).

You do not have to worry about this one. Audio host performs this for you. All you need is to tell audio host amount of processing latency your plug-in has.

To test stability you may perform a simple test: create 'infinite loop' application, that sends and receives to/from GPU 20 MB of data (that's roughly 120 audio streams at 44.1kHz), and leave it in background. Now start audio application and load some project. If no glitches are happening then 'gpuhost' idea works fine, and so plug-ins may work without a single problem (I can't do such test myself because I'm no expert in OpenGL or Direct3D, sorry).

GPU Delay - A delay plugin running on a graphics card