Is the Labview Runtime Environment sufficient to support utilizing a GPU?

[Don98103]

Thanks. Looks like there is a reasonable chance this will work – worth charging forward for now.

Any suggestions on where to look for "instructions" for selecting and executing some sample GPGPU routines while a "baseline scenario" is running in order to observe the impact of GPGPU on the "baseline scenario"?

[MathGuy]

Actually, the GPU Analysis Toolkit ships with three examples that I designed for just such a benchmarks. One performs a multi-channel FFT - another a dense matrix multiplication. The third runs combinations of the other two (for multi-device, multiple kernel or both scenarios).

Each example has a display component which is indicative of how you might visualize the results of the computation. The FFT example even allows you to adjust the data sizes (i.e. the channel count and depth) so you can investigate resource<->display behavior.

You can see a video of an older version of the FFT example on YouTube: https://www.youtube.com/watch?v=1GexYx7nu8Y. At that time, I used NI's USB DAQ interface to capture live stereo audio from the headphone jack of an iPod. The toolkit's example uses simulated data but the display and computation demands are the same (using the default settings).

[Don98103]

Thanks.

The demo on YouTube demo gives me a feel for what is possible on a system with an older CPU and a moderate performance video card for GPGPU. If I understand correctly, every 20 msec the demo system is doing 1K FFTs with 1K samples per FFT, while at the same time acquiring 50K samples per second, and displaying results based on the acquisition and FFTs. The GPGPU is estimated to be taking less than 5% of the available time.

[MathGuy]

Yes. The only thing I would add is that all 1024 1K samples are transferred to and from the GPU every 20ms for each computation even though only each acquisition only involves one new 1K sample.

This was to mimic the total cost (from the LabVIEW app perspective) of a live 1024 channel system in action. Each 1K sample gets copied into a row of the 2D LabVIEW array storing all 1024 1K samples. This array is what's plotted on the intesity graph.

The only performance aspect this does not replicate is the movement of the previous 1023 samples within CPU resources for purposes of display. This, however, should be relatively small compared to the other transfer operations.

[Don98103]

I'm hoping the sample executables in the LabVIEW GPU Analysis Toolkit can simply be copied onto and executed on a properly prepared (LabVIEW RTE, graphics card, graphics card driver) target machine. Furthermore, since the sample executables were prepared for the purpose of demonstrating the use of LabVIEW for performing GPGPU, I'm hoping the user interface is rather straight forward and documentation is provided, or built into the examples, making use of the sample executables somewhat self-explanatory. If using the examples is this simple, it would suit my purposes fine. In my role I don't have a need to understand developing executables - and it's not something I've done other than in a very rudimentary fashion in a classroom setting. I just need to confirm that the hardware configuration I'm tentatively planning to set up has a reasonable chance of performing acceptably if others try to develop GPGPU LabVIEW executables for it in the future. Is using the examples from the LabVIEW GPU Analysis Toolkit this simple? If not what else is required? The local National Instruments team will assist me as needed.

Thanks for the tremendous amount of help you've been providing me in this discussion.

[MathGuy]

The examples do have a friendly front panel and are documented. However, they are not built as standalone executables. While I know you'd like to grab-and-go in this case, I would actually encourage you to look at it as an opportunity to learn the deployment.

If your plan is to deploy custom GPU-based applications in LV, then you will need someone that knows how to build executable(s) as well as the installers for deployment. Doing this with an existing example is much easier than starting from scratch. Besides, this is a pre-requisite to deploying custom LV apps w/ GPU code.

I should also clarify that you don't need  a LV app doing specific GPU computations in executable form to test if it will work properly on certain GPU hardware. That can be validated from LabVIEW's development environment. I am not aware of any additional GPU overhead when performing GPU functions from an executable versus a VI.

Does this make sense?

[Don98103]

It makes sense.

I understand you to be telling me that I will need to install a LabVIEW license and a LabVIEW GPU Analysis Toolkit license to use the examples from the toolkit. I can get help with that locally from National Instruments.

Seems to me that providing the examples as standalone executables would be a worthwhile addition for cases like mine where grab-and-go would meet the immediate requirements. Or, are you telling me that grab-and-go is not possible for GPGPU LabVIEW applications? Based on my understanding of our many developers - I'm not one of the developers - creating non-GPGPU LabVIEW applications and providing the applications on a grab-and-go basis to our many users for use on our workstation equipped with LabVIEW RTEs, I've been assuming grab-and-go is equally possible for GPGPU LabVIEW applications. Or, does GPGPU add a complication the precludes grab-and-go?

Thanks.  

[MathGuy]

Short answer: Yes - you only need an appropriately versioned LabVIEW RTE.

• You do not need a LabVIEW or GPU Analysis Toolkit license on the machine where the application is run.
• You will need both a LabVIEW and GPU Analysis Toolkit license on the machine where the application is designed and built.
• You cannot build applications where the GPU functionality supplied w/ the toolkit is 'dynamically' loaded unless all required VIs are statically compiled into the LabVIEW application.

Details:

While this only took me an hour to validate, I've had no time over the past several months to look into your last question. To test this, I removed all remnants of NI products from system A. On system B, I created a LV project (from scratch) which used code from the existing Multi-channel FFT example and defined a Build Specification to build a standalone LV 64-bit application. After building the application, I copied the files over to system A and ran it.

NOTE: The build process cannot automatically find one of the GPU toolkit's required resource files because it is delay-loaded. For standalone applications performing GPU computations, the appropriate resource file must be copied to a specification location in the Window's system directory. Here's a link with that describes the problem and the potential workarounds: https://decibel.ni.com/content/message/52818. If you have control over the machines where the application is distributed, it is possible to create an installer that will automatically copy the required files to the correct locations.

After the first run, I was given the error - no LabVIEW runtime exists and was given the option to download the runtime. I selected this option and was taken to NI's website where I downloaded the runtime installer and ran it. After a reboot, I ran the application again and it ran successfully (see the following snapshot):

Below is a snapshot of the build project I created. I just copied the example VIs over to My Computer from the examples directory and configured the build process to auto-start the top-level example VI when the executable is run.

This is what I meant by not being grab-and-go. The examples are not pre-made into standalone applications for distribution. However, it's not hard to do so and it's an exercise you (or someone in your company) should go thru if you plan to leverage it more than once.

Final note: I did this on Windows 8.1 64-bit using LV 2013 64-bit and built a 64-bit application. You can build 32-bit versions but the steps are slightly different depending on the Windows OS.