I plan on using c++/cli for the managed/unmanaged code interaction, but I am unsure of how this will work with the OpenGL or SceniX (NVSG) graphics part. How to deal with the render area and event loops? Can I render directly to a C# form, and if so how to do this? Can I start up all the unmanaged stuff from a thread in C#, and let the rendering loop + cuda run in this thread, or is this a bad solution performance wise?
I have a utility written in C that I want to call from C#. (The C# will also do some processing on the GPU via GASS )
The problem is that C# is managed code running garbage collection and the C utility needs to permanently grab a largish chunk of RAM, (will be used frequently over a period of minutes to hours and freed when application closes). I haven’t been working with .NET for that long and have no experience with this kind of interaction.
Can anyone advise, Please, it would be especially helpful if they can tell me the 'Gotcha’s and/or point me to some straightforward examples. NB The utility buffers a series of GB+ sized arrays, so speed is very important and I want to keep the interface between the C and C# as simple and fast as possible.
PS Sometimes it will be C# between the utility and GPU or othertimes C or C++
I can hear that you got someof the same challenges that I have.
Goto www.apress.com and make a search for c++/cli, these are some good books that I can recommend. You wont have to read it all though…
C++/CLI is the technology you want to use, it performs best both in memory use and speed, by a long shot! It will allow you to pass an unmanaged pointer of your managed data to your native function to do native work (at native speeds) without copying the data. As native code dont know about the array lengths of any pointer, I gues you should also pass the array size with you arrays. You have to create this managed/unmanaged wrapper in a c++/cli project. What happend under the covers is that the ‘managed’ handling of the data is put on hold. (Normally in the managed world all data on the manmaged heap is betting moved around in memory at random times in order to ‘manage’ them, something which native pointers cannot handle.) When your dataarrays are created in managed code, deletion is best taken care of by managed code. Data arrays created on the native heap is better controlled by native code. As you have GB sized data, you are most likely to compile 64 bit apps. 32 bit apps can utilize about 1.7GB of ram per process and is too limited I would guess for you. Note that when making c++/cli native/managed wrappers, this code will execute in the same process, and so the native + managed memory total will be limited by 1.7gb. Because of this you should compile your native code + wrapper to x64 bit code, and you should set your managed projects to compile into x64 bit code as well. Managed code have the ability to be compiled ready made for both x64 and x86 code at once, but I have not been able to include any native wrappers into managed code with this compiler option set, use only x64 bit compiling. (You cannot link together x64 and x86 native code in the same process, thenm you will get a compiler error that is not so good:) Lastly, to include native c compiled code (and not c++) you will have to declare you native c functions in theis header file in a special way that enables them to be called by c++ native code. If you got the option to (re)compile this c code to c++ you may avoid this problem. Lastly, I don’t see any problems with running the computational code in some other thread I think, as long as you avoid running gui stuff from other that the main thread.
First, many texts talks about the cost of actually making the function calls (millions of them) and not about passing large chunks of data only a few times. As long as you can make each individual native c function called from C# do ‘a lot of’ work,’ you’ll be fine.