Can either NIDAQ or LabVIEW Queues tell a motherboard's chipset to make a copy of the data as it comes in off the PCI bus?

[tarheel_hax0r]

We're thinking about upgrading our hardware to something like the Tyan S2885 Dual Opteron motherboard:

http://www.tyan.com/products/html/thunderk8w.html

I was looking at that board - it's got two memory banks, one for each processor - and thinking about LabVIEW, where there are no pointers, and where, if you're not careful, your data will be passed by copy, rather than by address/reference, and it occurred to me: Can either NIDAQ or LabVIEW Queues tell the motherboard's chipset to make a copy of the data that's coming in, then send one copy to a thread on the first processor, and the other copy to a thread on the second processor?

To put it
another way - since LabVIEW tends to pass things by copy, is there a way to ensure that these copies [especially of data coming in off the PCI bus] are done in hardware [very fast] rather than in software [very slow]?

Or am I asking for way too much?

[tarheel_hax0r]

Granted, some of this is gonna be Intel -vs- AMD specific.

In the case of the Opteron & HyperTransport, I guess they've brought the chipset inside the CPU itself.

Nevertheless, I'm wondering if there is some way that LabVIEW [or NIDAQ] could tell the memory subsystem to copy a range of memory on its own, rather than having to go to all the work of loading the memory into one of the processors [for use by the first thread] and then copying it all over to the second processor [for use by the second thread].

Particularly since the default behavior in LabVIEW is pass by copy, rather than pass by address/reference...

[tarheel_hax0r]

And it doesn't necessarily have to be LabVIEW Queues that we're talking about here.

I just chose "Queues" because, as I understand it, that's what you're supposed to use in LabVIEW when you're trying to get two different threads to operate on the same piece of data.

In our case, one thread will work on the data itself [time domain] and another thread will take the DFT and work on the transformed thread [frequency domain].

If there's a structure other than Queues that can do this, I'm happy to use it.

But what I'm really interested in is the question of whether either LabVIEW or NIDAQ can bypass the operating system and perform the copying of the data in hardware [potentially very fast], or whether LabVIEW has to tell the operating system to copy th
e data in software [potentially very slow].

[tarheel_hax0r]

'and work on the transformed thread [frequency domain]'

should read

'and work on the transformed data [frequency domain]'