We could really use this.

[tarheel_hax0r]

I'm asking this question because LabVIEW graphics feel just a little slow to me, especially on slightly older hardware [which many of us have to deal with on a daily basis], and I was wondering if anyone had any suggestions for how to maximize LabVIEW's graphics performance, to include graphics card recommendations and configuration advice.

Apparently LabVIEW uses the "Mesa" implementation of OpenGL. The Mesa home page is here:

http://www.mesa3d.org

There are several Mesa hardware acceleration projects, but they seem to be heavily oriented towards Unix/XWindows [as opposed to Win32], and it's not at all clear whether these projects are still active:

Direct Rendering Infrastructure
Utah GLX

As of LabVIEW 7.0, NI seems to be packing all of its graphics stuff into one big file called "mesa.dll", which lives in at least three different places:

C:\Program Files\National Instruments\LabVIEW 7.0\resource\mesa.dll
C:\Program Files\National Instruments\Shared\Mesa\mesa.dll
C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\7.0\mesa.dll

"Mesa.dll" is a very large file [nearly a megabyte in size], but it's not clear to me whether it's a software implementation of the Mesa interpreter, or a hardware implementation of various graphics chipset drivers, or both [or neither...]. It's also not clear that there is any way to tweak the Mesa configuration, especially as it concerns the specific graphics chipset you might have on your platform.

When I Google the NI forums [or search them directly], I get very few hits on mesa.dll, but I did stumble across this thread:

LabWindows 7.0 Bugiest Compilier Ever?

Within that thread, an NI employee seemed to suggest that if you are using LabWindows/CVI, then downloading updated versions of the CVI Runtime would in turn update [?] the mesa.dll file.

But that's about all the "mesa.dll" advice I could find.

So does anyone have any suggestions on how to get the best performance out of the LabVIEW/Mesa/OpenGL stuff? How do I get the latest version of "mesa.dll"? Which graphics chipsets work best with it? Which graphics chipsets should I avoid? Are there any configuration files or registry settings I should tweak to get better performance? And are there any busses I should use or avoid [PCI, AGP 1X/2X, AGP 4X/8X, PCIe]?

I'd be especially interested in any good "Mesa-capable" PCI graphics chipsets for some older computers we have that lack AGP slots.

Thanks!

[tarheel_hax0r]

I'm gonna bump this 'cause I'd like to hear an official answer from someone at NI.

At this point, I guess I'd be happy with an answer to the following question: When working on a Win32 platform, is LabVIEW's graphics package [founded on the underlying Mesa implementation of OpenGL] essentially just a software package [i.e. LabVIEW's graphics instructions are necessarily interpreted by the computer's CPU, and cannot be offloaded to the computer's graphics chipset], or is LabVIEW's graphics package capable of being offloaded to the computer's graphics chipset [what we call "hardware acceleration"]?

I ask because I posted a query over at the Mesa forums, and the Mesa guys tell me that Mesa on Win32 is a software package [not hardware accelerated].

Thanks in advance.

[Philip_Courtois]

Hi Tarheel,

Your question is very valid. The answer is that software products from NI (ie. LabVIEW) that uses the Mesa 3D Graphics Library, are not currently able to take advantage of any hardware acceleration on the graphics chipset. The Mesa Graphics Library currently used by the NI software platforms is strictly based on software-based rendering.

[tarheel_hax0r]

Thanks for the reply [I really appreciate it]. During the course of a day [or a week], I work on about a gazillion different machines [some dating back to circa 1997, and running at speeds as slow as 500MHz], and I had noticed that on the older machines, there are some real problems with graphics rendering.

I guess those machines will not benefit from any further upgrade of the graphics hardware, and we're gonna hafta invest in newer hardware - in fact, in the very near future, we are looking at a big new series of upgrades, and it was good to learn this in advance.

PS: I know it would make LabVIEW less stable if you were to force a hardware acceleration of the Mesa library [graphics drivers being among the flakier, more unstable entities in the greater world of Information Technology], but, long term, I think it would be a very, very nice option [not requirement] to have in future versions of the platform [i.e. it would be very nice if the user could choose the option of offloading Mesa/OpenGL instructions to the graphics chipset, or, for stability purposes, choose to forgo the offloading and let the CPU interpret the graphics].

Thanks again!

[tarheel_hax0r]

You know, the more I think about it, the more I'm inclined to put hardware acceleration of mesa.dll near the top of my wish list of features [or at least options] that I'd like to see in future versions of LabVIEW.

[PPLLC]

I'll second your request Tarheel! I am devling into motion tracking applications that would benefit enormously from hardware acceleration. All of the normal methods for rendering the trajectory of a moving object, in my case a person's arm, either result in unpleasant update rates or undesirable CPU usage. I was hoping to see something useful happen in LabVIEW 8, so I am really anxious to acquire LV8. It would seem that as the LV developer community tackles more tasks that generate 3D data/datasets this will become more and more of a road block.

Chris

[tarheel_hax0r]

I'll second your request Tarheel! I am devling into motion tracking applications that would benefit enormously from hardware acceleration. All of the normal methods for rendering the trajectory of a moving object, in my case a person's arm, either result in unpleasant update rates or undesirable CPU usage. I was hoping to see something useful happen in LabVIEW 8, so I am really anxious to acquire LV8. It would seem that as the LV developer community tackles more tasks that generate 3D data/datasets this will become more and more of a road block.

You might also be interested in this LabVIEW thread, and the Slashdot thread which spawned it:

LabVIEW Development Team: Windows Vista May Degrade OpenGL

http://forums.ni.com/ni/board/message?board.id=170&message.id=136018

Windows Vista May Degrade OpenGL
http://slashdot.org/article.pl?sid=05/08/06/177251

[PPLLC]

Thanks for the threads. I ended at your thread - I wish I had started there as it would have saved me a lot of research into LV graphics. Another thought for any NI people who may be looking... nVidia uses a unified driver which might be more practical to support for hardware acceleration be it OpenGL or DirectX. I don't think there would be anything wrong with only supporting one video manufacturer (personally I don't care which one they support as long as the supported company has a good product line and good track record). The other option I could see is making the code for the mesa dll available so that we could add hardware acceleration on our own. Of course, this assumes that OpenGL will still exist in some manner in the future either directly supported or as a viable-add on to a Windows OS.

Some of the decisions coming out of Redmond sure make me think twice about switching to Linux especially as NI seems to be expanding their support of it.

Chris

[NathanT]

All,
      Hardware acceleration is supported in LabVIEW for both the ActiveX 3D graph and the 3D Picture Control rendered in a scene window.  Mesa is only used on the front panel controls such as knobs, booleans, etc.  Check out the Setup Window. 

Nathan

[THailey3]

Hi,

Nathan is correct.  Hardware acceleration support for the 3D Picture Control is new in LabVIEW 8.2.  So as of LabVIEW 8.2, here is the current state of LabVIEW's hardware acceleration support:

Feature/functionality	Supports hardware acceleration?
LabVIEW 3d controls on the front panel such as knobs, booleans, etc. (these are rendered with Mesa)	No
LabVIEW 3d graphs (ActiveX)	Yes
LabVIEW 3d picture control rendered into the scene control	No
LabVIEW 3d picture control rendered into the scene window	Yes

Hope this helps!