How to change CUDA's linking directory? - cuda

I've been using CUDA 4.0 for sometime now. I've recently downloaded and copied CUDA 4.1 new API (I need Thrust's lambda expressions support) but my solution's properties are still linked to the old 4.0 API. How do I change it dynamically? My guess is that I need to change the $(CudaToolkitLibDir) variable, but how exactly?
edit : i'm asking this because i'm trying to use thrust::placeholders

To answer the specific question:
For VS2005 or VS2008, you need to change the Custom Build Rules to pick up the CUDA 4.1 rule instead of 4.0. See this post for more information.
For VS2010, you need to change the Build Customization to pick up CUDA 4.1 instead. See this post for more information.
Looking at the comments, it's also clear you will need to install a CUDA 4.1 driver which you can download from the NVIDIA website. You said your program crashed on the first cudaMalloc() when you updated to 4.1, you should check the error message (in general you should check all API calls for errors). The first CUDA API call will return an "Insufficient Driver Version" message if your driver is not up-to-date.

Related

Installing CUB in nvidia nsight

I want to use CUB with NVIDIA Nsight. I looked for tutorials on the internet for doing that, but I didn't find anything, even in the official pages pf CUB.
What do I need to do in order to use CUB in code I write using NVIDIA Nsight?
There is no need to do any installation since the CUB library is implemented as C++ headers check it in the section number 6 in this page here. The only thing you need to is to add the path of the library to the includes of the projects as follow:
right click on your project go to properties, after that go to C/C++ general then click on Paths and symbols. in the Includes tab ( the first tab) you add the path of your library that's all.

How to create a PPAPI plugin for Google Chrome in Windows?

I am new to PPAPI development and have downloaded the already examples from here
However, even after coming across the documentation,
I am not able to build the project.
I have Microsoft Visual Studio 2010, Windows OS and Chrome:30.0.1599.65
I understand that once a dll is created, using the regsvr32 command will register the plugin, although getting the dll, even with available code, seems tough for me. Any help for building the dll is appreciated.
You will want to start here to download the and set up the SDK: https://developers.google.com/native-client/sdk/download
This page will take you through how to build and run the examples: https://developer.chrome.com/native-client/sdk/examples
This page goes over how to actually create your own plugin: https://developer.chrome.com/native-client/devguide/tutorial/tutorial-part1
And then you should read this entire section to code and structure your application: https://developer.chrome.com/native-client/devguide/coding/application-structure
If you need any third party libraries be sure to check here: https://chromium.googlesource.com/webports
Edit: Forgot to mention that you will want to use the same version of the pepper api as the version of chrome you're running (in this case pepper_30). Also, you have to use the NaCl toolchain (one of either glibc, newlib, or pnacl); you can't use the Visual C/C++ toolchains. I recommend trying pnacl now that it is available, as that is by far the most cross platform version, but if you run into trouble, you'll probably want to use the newlib toolchain as it has better support.

Box-API: How can I add a strong name to a 3rd party assembly written for the .NET Portable Subset

I am trying to strongly name a 3rd party API that I have the code for but it's using a 3rd party DLL/NuGet Package that is also not strongly named and I'm having a lot of trouble.
I'm using the Box Windows SDK and the API was written in the .NET portable subset and supports .NET for Windows Store Apps, .NET Framework 4 and higher, SL4 and higher, and Windows Phone 7 and higher. Granted, I do not need all of these but I do need the .NET 4 and Silverlight versions. The API already works wonderfully and runs fine on its own. It would with my application also, if all my projects were unsigned but they aren't. We use strongly named assemblies for our Silverlight application in order to make use of application library caching.
Anyway, I have the source code for the API so I simply added my PFX file to the project to sign it. I then get an error that a dependency that this API is using called NitoAsnycEx.dll is not signed. I do not have the code for Nito.AsyncEx.dll but normally this isn't such a problem, more of an annoyance. So now I have an age-old problem of needing to take a 3rd party DLL of which I don't have code for and sign it with my PFX or another SNK file.
I can do either and normally I use one of the processes so wonderfully explained in this post by Ian Picknell: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html. So I have followed that process and the IL signing tools seem to sign the DLL just fine.
To make a long story shorter, let's use the simplest version of the signing process where I already have a simple SNK file ready to go. Basically, I do this:
I can run ILDASM to get the .il file for this 3rd party EXE:
ILDASM Nito.AsyncEx.dll /out:Nito.AsyncEx.il
I can then run ILASM to get the signed DLL:
ILASM Nito.AsyncEx.il /dll /resource=Nito.AsyncEx.res /key=NPSAssemblyKeyNoPassword.snk
It works great and I get this result:
Method Implementations (total): 118
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully
So now I have a signed DLL. I go back to my 3rd Party API code and remove the old reference to NitoAsyncEx.dll and put a new one to this. I try to compile and then I get an error like this:
Error 44 The base class or interface 'System.Object' in assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' referenced by type 'Nito.AsyncEx.AsyncLock' could not be resolved r:\Data\GM\Source\GrantManagement\GrantManagement\3rd Party\Nito\Nito.AsyncEx.dll
I figure there is some problems using the portable .net library here but I'm not sure what it is. This same process normally works for me for Silverlight 4+ and Full .NET 4.5 framework libraries. Is there another ILASM or ILDASM set somewhere that will disassemble and reassemble the portable code correctly? Is this even possible?
I also tried to go and get the source code for the NitoAsyncEx.dll, which is open source btw, and compile it but that source code will not compile as it's missing some files. So currently I'm stuck with my integration of this API into my project and need a little assistance from any experts in the community.
Is there a way to sign this DLL correctly so we're not missing references to basic classes such as System.Object?
Is there a way to get around needing to sign this DLL at all and having it referenced from my projects?
UPDATED
The Box SDK has been updated and is now strong-named on nuget. This is thanks to the recent update to AsyncEx which strong-named the assembly.
As you mentioned, it's unfortunately out of our control that the NitoAsyncEx library is not strongly named. This library provides the ability to properly lock resources during an async/await call, and I do not believe there is a better alternative at the moment.
This being said, I may have a (hopefully temporary) workaround for you. I've downloaded the source from https://nitoasyncex.codeplex.com/ and was able to get it to compile. These are the steps I performed:
Removed the reference to MSBuild in the csproj
Copied the missing Dequeue.cs file from the packages folder
Resolved missing nuget references
Regenerated the AssemblyInfo.cs
Excluded the .tt template files from the project
Unloaded all other projects the SDK does not use
Here's the resulting solution:
https://cloud.box.com/s/7ikurtyajqmhq9p8q52x
I've successfully ran the resulting dll through the SDK's tests so hopefully this should cover what you need. I cannot guarantee the stability of this method, but having a working source should allow you to do any signing you need. From there, you should be able to drop the signed assembly into the SDK source and sign that assembly as well.

MvvmCross-based application is unable to load design-time view model

I've found a topic describing NullReferenceException in Windows Phone designer, however I believe this is a somewhat different issue, since it happens in all platforms and not related to MvvmCross plugins.
Designer (VS2012, Store/WP8/WPF apps) works fine for earlier versions of MvvmCross. I tried to compile a version that corresponds to 3.0.6 NuGet packages, and I can see that design-time model is loaded in all platforms.
Recent MvvmCross version causes all designer to raise NULL reference exception ("Object reference not set to an instance of an object") on all platforms.
Attempt to debug a VS instance didn't help: the call stack doesn't say much, and there is no MvvmCross code there.
The error is not related to the actual view/view model: I can remove all controls from the view, and the error is stil raised. The view model constructor code is never reached.
So it looks like there's some MvvmCross code (not from MvxView) that is unsuccessfully executed in at design-time. I wonder if this is a known issue and/or if there is a workaround to get designer work.
UPDATE. I created a GitHub issue with steps to reproduce the problem: https://github.com/slodge/MvvmCross/issues/347
This question moved to GitHub where there was lots of discussion and a few samples - https://github.com/slodge/MvvmCross/issues/347
From these samples, I believe we concluded the Nuget release 3.0.8.1 :
supports time data based on Blend-generated XML data files
supports design-time data based on simple C# classes
does not support design-time data where the data uses MvvmCross MvxViewModel as a base class
It isn't entirely obvious that developers should want to do the third thing (designtime data isn't real data?), but given that the overall MvvmCross manifesto broadly speaking aims to enable developers and to give them choice, then future MvvmCross will make this easier in the future.
In the meantime, if anyone wants to initialise objects at design-time, then there are a few helper classes around to enable this.
For example, the color plugin (and a small part of MvvmCross IoC) can be made available in the design-time environment using the MvxColorDesignTimeHelper - see:
https://github.com/slodge/MvvmCross/issues/323 (linked to MvvmCross throws NullReferenceException in Windows Phone Designer)
https://github.com/slodge/MvvmCross/blob/TibetBinding/Plugins/Cirrious/Color/Cirrious.MvvmCross.Plugins.Color.WindowsPhone/MvxColorDesignTimeHelper.cs
https://github.com/slodge/MvvmCross/blob/TibetBinding/CrossCore/Cirrious.CrossCore.WindowsPhone/Platform/MvxDesignTimeHelper.cs

.NET 4.5 / Assemblies loading from remote resource without loadFromRemoteSources=true

After installing .NET 4.5 beta, I noticed that my calls to Assembly.LoadFrom with a network path succeed without explicitly specifying "loadFromRemoteSources=true" in the application configuration file (whereas with .NET 4.0 this used to result in "System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.")
I wonder if this, if it indeed is new behaviour and not something special in my setups (I've not yet decompiled the respective reflection classes or debugged the loading process to examine the differences), is an intentional change in policy and will remain in the RTM version?
The docs don't seem to indicate this change in behaviour. http://msdn.microsoft.com/en-us/library/dd409252(v=vs.110).aspx. And I would have expected a notice of it.
If it does work this way, then you're granting full trust by default and invisibly to a potentially dangerous assemblies and I can't imagine that would be the order of the day.
Have you got it added to machine.config per chance?
Also I would create a small program and target it to the 4.0 platform and induce this exception. Then I would retarget it to 4.5 and see if indeed it's true. Then I'd move the binaries to another machine and test there.