GPU Delay - A delay plugin running on a graphics card

[zeep]

-delete-

[Uncle E]

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.

The high traffic of this thread should provide the best argument of all: an interested market. DSP plug-ins out-sell native plug-ins by about 10:1 at our shop, proving at least in my mind that people are willing to overcome small hurdles of hardware compatibility for the sake of quality.

[Aleksey Vaneev]

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

oblagon had the same problems.

Simply insert at least 10 instances of gpuDelay on various channels. Then start moving window sliders. I immediately get glitches and CPU spikes.

[Aleksey Vaneev]

The high traffic of this thread should provide the best argument of all: an interested market. DSP plug-ins out-sell native plug-ins by about 10:1 at our shop, proving at least in my mind that people are willing to overcome small hurdles of hardware compatibility for the sake of quality.

No, GPU plug-ins won't sell as much. What drives DSP card market is advertisement investments of major players. Since they won't be obviously interested in GPU plug-ins, GPU plug-ins from independent developers won't sell as much. What the hell? They will come into competition with major players: hence, they may even start a 'putting down' campaign.

So, defending against my whining is basically the same as defending from whining of all those 'major players' and their 'talking nicknames'. We'll be prepared.

[Nils Schneider]

---double post

[Nils Schneider]

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.

Yes I know that, but I think it's okay that way because I'm not sure if someone is running multiple hosts at the same time (i.e. multiple processes). And even if that's the case it's no problem, a little bit of memory for another invisible 640x480 bread-and-butter renderwindow should always be there

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.

It may not be totally clear what I mean, or it's not clear to me what you meant. I thought you wanted some sort of "batching", such as collecting what should be processed and then executing all at once. But as described earlier, that doesn't make sense. This would just cause the GPU to idle until all "packets" are collected and then it may be too busy to be fast enough.

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).

Good idea. I'll create a little "stress test" application that can be started. with adjustable data amount per second.

What graphics card do you use to test and which bus interface and speed? Buffer size?

If another thread than the main thread of your host is at a high load (high overall CPU load in task manager but low load in the host's CPU meter), the transfer back from GPU to CPU is slow.

[Nils Schneider]

No, GPU plug-ins won't sell as much. What drives DSP card market is advertisement investments of major players. Since they won't be obviously interested in GPU plug-ins, GPU plug-ins from independent developers won't sell as much. What the hell? They will come into competition with major players: hence, they may even start a 'putting down' campaign.

You're right I'm sure the big players don't like what I'm doing. But hey, who is talking about selling?. I didn't receive any commercial offers and I'm to lazy for a marketing campaign, and I do also have no knowledge about how to do good marketing.

I may create a little homepage with a Donate button, that's it.

[Scotty]

That would be great for the user community but perhaps you could link up with another developer who has those assets (marketing/distribution) and use your talents collaboratively to make a few more bucks for you and those who depend on you.

[Tony Ostinato]

I used to do demo work at namm for fairlight. the nice thing about their card coming out is that it means eventually someone else will do the same thing, only affordably.

from pro tools tdm to the sharcs to poco and uad-1 people have been very interested in dsp plugins for a long time i think its extremely naive to think thats going away.

then again stefan deystrom didnt listen to me when i talked about how he should have adjustable swing quantize, or even any swing quantize at all, in smptetrack saying "no sequencer developer is going to waste time on stuff like that", so tell me where hybrid arts is today? freeware.

i wouldnt be suprised if this gpudelay gets written up in the mags, people are fascinated.

[Aleksey Vaneev]

Yes I know that, but I think it's okay that way because I'm not sure if someone is running multiple hosts at the same time (i.e. multiple processes). And even if that's the case it's no problem, a little bit of memory for another invisible 640x480 bread-and-butter renderwindow should always be there

But I think the problem is a little bit different: it may be true that graphics drivers were not fully designed for such kind of GPU calculation (and getting data OUT of graphics card), and so they may interfere with process itself.

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.

It may not be totally clear what I mean, or it's not clear to me what you meant. I thought you wanted some sort of "batching", such as collecting what should be processed and then executing all at once. But as described earlier, that doesn't make sense. This would just cause the GPU to idle until all "packets" are collected and then it may be too busy to be fast enough.

I mean that all you need is to transfer N streams to graphics card, start N shader programs, and ask for any data available from the previously started N shader programs. Audio host will take care of processing latency itself (if you have three GPU plug-ins in sequence you'll have 3x latency of a single plug-in). You do not have to worry about audio processing precedence at all. And there are no idle cycles at all as you see them. You give a task to process 40 streams and they are processing. What else do you want? If you GPU is more powerful, set this to 80.

What graphics card do you use to test and which bus interface and speed? Buffer size?

As I've replied earlier I use NVidia 7800 GTX on PCI Express. RME Hammerfall 9632 sound card is running at 512 buffer size. This is an 'ideal' setup, and still gpuDelay does not work well in practical scenario (several instances).

If another thread than the main thread of your host is at a high load (high overall CPU load in task manager but low load in the host's CPU meter), the transfer back from GPU to CPU is slow.

So, I guess this fact is a 'vote' for creation of such external 'gpuhost' application.

[Radek]

People are more interested in quality of effects/synths what are coming with DSP cards than an actual hardware imho (those cards aren't really that powerfull processing wise). It doesn't matter how much faster a GPU can be if there will not be as many (and quality) plugins for it. Consider also that costs of developing for pixel shaders will be higher than for writing say a C/SSE code.
Intel recently twiced perfomance per clock of SSE vector unit in Core2 processors. With dualcores becoming a common thing (and quad core on a horizont for more demanding aplications) it's hard to see why someone should invest for additional software and a graphics cards instead of getting just a faster cpu.

So... there is a possibility but some serious results (say a complete synth showing significant quality and perfomance improvement) first, please.

Good first step nevertheless.

[Nils Schneider]

But I think the problem is a little bit different: it may be true that graphics drivers were not fully designed for such kind of GPU calculation (and getting data OUT of graphics card), and so they may interfere with process itself.

I mean that all you need is to transfer N streams to graphics card, start N shader programs, and ask for any data available from the previously started N shader programs. Audio host will take care of processing latency itself (if you have three GPU plug-ins in sequence you'll have 3x latency of a single plug-in). You do not have to worry about audio processing precedence at all. And there are no idle cycles at all as you see them. You give a task to process 40 streams and they are processing. What else do you want? If you GPU is more powerful, set this to 80.

The problem is, when "asking" for any data available, it's too late, the GPU speed is not the problem, the problem is the transfer back to the system. And because of that, the data must already be transferred back to the system before the host is even asking for it. And this is already working like a charme, if the transfer is completed, the thread is idling (waiting for the next "transfer next data to GPU" event). And of course, no two instances are transferring at the same time, they're all queued of course. graphics boards are no thread safe

As I've replied earlier I use NVidia 7800 GTX on PCI Express. RME Hammerfall 9632 sound card is running at 512 buffer size. This is an 'ideal' setup, and still gpuDelay does not work well in practical scenario (several instances).

This is indeed a good setup, but I promise that if you are having such results, this is not normal.

So, I guess this fact is a 'vote' for creation of such external 'gpuhost' application.

I could outsource the code to an external executable, but it wouldn't make a difference, if an exe is waiting for commands or a thread....

But it may also be time to continue privately as I of course can imagine why you would prefer such a GPU host

[Nils Schneider]

People are more interested

I think this should read "I'm more interested"? There are enough people that want to free their CPU from effects that eat up a lot of performance I'm sure about it. Adverts from BionicFX wouldn't have reached such a popularity otherwise.

So... there is a possibility but some serious results (say a complete synth showing significant quality and perfomance improvement) first, please.

Possibility for what? It seems that no one understands my attempt. I won't post it for the third time I won't develop a synthesizer because I just don't need one.

(Btw I tested, adding some hundered sine waves on a GPU in realtime is nice though.....)

[juha_p]

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

oblagon had the same problems.

Simply insert at least 10 instances of gpuDelay on various channels. Then start moving window sliders. I immediately get glitches and CPU spikes.

Have you tried w/ different PCI Latency settings --> normally PCI Latency for graphics is set to 248-255 as default (even 32 or 64 is defaulted in BIOS) ... sometimes it's too much for sound device to get the best performance (soundcard PCI latency is normally set to 32) ... lower PCI latency foe graphics card to 64-128 and see if it helps anything.

PCI Latency Tool - http://downloads.guru3d.com/download.php?det=951

Also, graphics HW acceleration and mouse sampling rate/speed settings can be affecting in these issues you get.

EDIT: Noticed that you have a PCIe card there --> you can't adjust latency for it --> maybe increasing value to 96-248 for soundcard helps a bit.

Juha

[Aleksey Vaneev]

The problem is, when "asking" for any data available, it's too late, the GPU speed is not the problem, the problem is the transfer back to the system. And because of that, the data must already be transferred back to the system before the host is even asking for it. And this is already working like a charme, if the transfer is completed, the thread is idling (waiting for the next "transfer next data to GPU" event). And of course, no two instances are transferring at the same time, they're all queued of course. graphics boards are no thread safe

This is technical details that are resolved by introducing plug-in latency (your gpuDelay already works at 1024 sample latency). What I was trying to say is that there is no problem to transfer 40 streams instead of 1 stream like you do now, while this can probably speed-up GPU-CPU memory transfers.