GPU Delay - A delay plugin running on a graphics card

[oblagon]

This is awesome ! The chorus works fine here. I stopped duplicating the plugin when i reached 60 effects.

[Aleksey Vaneev]

This is awesome ! The chorus works fine here. I stopped duplicating the plugin when i reached 60 effects.

What was your CPU load then? And what kind of video-card/computer setup do you have?

[oblagon]

This is awesome ! The chorus works fine here. I stopped duplicating the plugin when i reached 60 effects.

What was your CPU load then? And what kind of video-card/computer setup do you have?

dual p 3.2 (running at %120), geforce 7600 gs. There was some small cpu usage. Big cpu spikes when scrolling, moving windows etc. Audio playback was completely stable though. I had buffer set to 2000 and soundcard latency to 20ms.

That was a lab experiment. Using 60 fx would be impossible in a project that is already loaded with synths and effects.

[Aleksey Vaneev]

I'm now really worrying about throughput bottleneck... 60 stereo instances at 44.1kHz is only 5.2 MB to GPU and 5.2 MB from GPU. Only 10.5 MB/s of throughput and one core of CPU is maxed. This is far from being encouraging considering internal memory bus throughput of CPU is more than 6 GB/s.

[Kingston]

I'm not awfully familiar with data moves through AGP and PCI busses, so if someone could give a recap that would be great.

Isn't AGP quite the highspeed bus? When we're running games AFAIK there are riduculously large data moves between CPU and GPU (physics related for example). How come it's so difficult to stream data back and forth with such measly bandwidths that 44.1-96khz audio create? Is there some realtime requirement I'm not understanding here, that chokes the busses? Interrupts? How do they relate to all this?

[cYrus]

I'm now really worrying about throughput bottleneck... 60 stereo instances at 44.1kHz is only 5.2 MB to GPU and 5.2 MB from GPU. Only 10.5 MB/s of throughput and one core of CPU is maxed. This is far from being encouraging considering internal memory bus throughput of CPU is more than 6 GB/s.

since when is "small cpu usage" the same like "one core of CPU is maxed"?

[akisd28]

I suppose Aleksey is talking about this:

dual p 3.2 (running at %120)

...but I think what was meant is that it is overclocked @ 120%. Am I right, oblagon?

[Aleksey Vaneev]

I was supposing 120% in means 1 CPU core is maxed, while at the same time 20% of second core is in use.

[Aleksey Vaneev]

I'm now really worrying about throughput bottleneck... 60 stereo instances at 44.1kHz is only 5.2 MB to GPU and 5.2 MB from GPU. Only 10.5 MB/s of throughput and one core of CPU is maxed. This is far from being encouraging considering internal memory bus throughput of CPU is more than 6 GB/s.

since when is "small cpu usage" the same like "one core of CPU is maxed"?

I was not speaking about 'small CPU usage'. I was commenting exactly the opposite: that it seems that CPU<->GPU transfer of 10.5 MB per second maxes one CPU core.

[fake]

Thanks munchkin for the list/info.

I've held off upgrading the card for now and will be looking into it further.

fake

[Aleksey Vaneev]

OK, I've re-read what oblagon have replied. Probably, I was not reading good enough. I was looking for %% number and hooked on %120. I've skipped 'some small cpu usage' wording because in the context it had meaning something like 'steady cpu usage' (in contrary to spikes when changing windows).

OK, a real CPU usage would be better.

[Aleksey Vaneev]

I have tried something like this myself: added 12 instances of gpuDelay in Sonar5. Indeed, most of the time CPU was jumping between 2 and 4. That's pretty low. But I've also had problems with graphics: when I was scrolling. After adding a couple of more instances, CPU spiking become a problem - Sonar5 have stopped several times due to drop-out. (my computer is Athlon X2 4400+, GFX is NVidia 7800 GTX).

So, it seems that memory bandwidth is not a problem?

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. I believe these problems can be fully resolved by creating a 'gpuhost' kind of program I was describing previously (but of course, this is still a bit uncertain because there's no guarantee CPU won't be spiking if such GPU program will be working in background, in parallel to audio host application).

[bleebsen]

Isn't AGP quite the highspeed bus? When we're running games AFAIK there are riduculously large data moves between CPU and GPU (physics related for example). How come it's so difficult to stream data back and forth with such measly bandwidths that 44.1-96khz audio create? Is there some realtime requirement I'm not understanding here, that chokes the busses? Interrupts? How do they relate to all this?

AGP was specifically designed for graphics cards. So it's easy to get huge amounts of data into the card very quickly (agp cards can even address pc memory directly), but IIRC the main problem is getting the same data out of the card again at the same speed. A normal graphics card wouldn't have much data to send back to the computer.

Interrupt Requests (IRQs) occur if a card has "urgent" data to deliver. F.e. if your network cards input buffer was full it would rise an IRQ so the driver would get the data from the card and clear the buffer again. Using IRQs is the opposite of "polling" - periodically calling the card to see if there's data.

("normal" VGA cards do not even need IRQs)

This whole bus system wasn't designed for isochronous transfers. So streaming applications which NEED a guaranteed throughput suffer first.

Hope this helped a little, unfortunately I'm not a device driver programmer

[munchkin]

Thanks munchkin for the list/info.

I've held off upgrading the card for now and will be looking into it further.

fake

Your welcome. I wanted to make sense of all this because it does seem complicated. I still don't understand what the difference is between PS2.0b and PS3 or whether a memory interface of 128bits rather than 64bits will make a difference with GPU plugins.

I'm holding off too until it's a bit clearer.

[munchkin]

Isn't AGP quite the highspeed bus? When we're running games AFAIK there are riduculously large data moves between CPU and GPU (physics related for example). How come it's so difficult to stream data back and forth with such measly bandwidths that 44.1-96khz audio create? Is there some realtime requirement I'm not understanding here, that chokes the busses? Interrupts? How do they relate to all this?

AGP was specifically designed for graphics cards. So it's easy to get huge amounts of data into the card very quickly (agp cards can even address pc memory directly), but IIRC the main problem is getting the same data out of the card again at the same speed. A normal graphics card wouldn't have much data to send back to the computer.

Interrupt Requests (IRQs) occur if a card has "urgent" data to deliver. F.e. if your network cards input buffer was full it would rise an IRQ so the driver would get the data from the card and clear the buffer again. Using IRQs is the opposite of "polling" - periodically calling the card to see if there's data.

("normal" VGA cards do not even need IRQs)

This whole bus system wasn't designed for isochronous transfers. So streaming applications which NEED a guaranteed throughput suffer first.

Hope this helped a little, unfortunately I'm not a device driver programmer

Does the same problem occur with PCIe? Isn't PCI designed to cope with two way data transfer? My DSP cards are PCI.

@Aleksey - could you design a GPU host? If so we will willingly test it (I'm speaking for everyone here... )

Is a GPU host a similar concept to a wrapper? FXpansions produce wrappers - perhaps they could have a go at a GPU one? (A desperate attempt to rope in more devs. )