Monday, 19 March 2012

Using Nsight with a GTX 590

Update: Nsight Development Platform, that is, Parallel Nsight v2.2 finally introduces the single-GPU debugging capability. This is good and allows you to skip the following paragraph.

The only way to make serious CUDA debugging is by using Parallel Nsight by NVIDIA, but it has a drawback: it takes two GPUs. So, you can remotely connect to a GPU-powered machine or you can do it locally, by installing two NVIDIA video cards on the same host. I chose the latter, and bought a GTX 590, a dual-GPU video card that NVIDIA itself considered "not profitable" and consequently stepped down the deliveries. Two GPUs are needed because one of them actually runs the kernels, whilst the other one "inspects" the memory banks of the former. Because of this, you must explicitly disable the SLI functionality, which makes the two GPU a single one:

Disable SLI by clicking "Disable multi-GPU mode"
So, one GPU is going to run the kernels, and the other one is used to "look inside" the video memory. Because of this architecture, the OS can't use the same GPU that run the kernels, so you must connect your screen on the other one. If you want, you can explicitly choose which GPU to use with the method cudaSetDevice().

Parallel Nsight has another, implicit drawback: it is a Windows-only application. In particular, you are going to need the full version Microsoft Visual Studio (VS Express is not supported). Windows has a functionality named timeout detection and recovery (TDR) that automatically determines if something is wrong with the video card driver and resets it. As the debug activity basically halts the execution of the kernels, TDR must be disabled:

Disable TDR by setting WDDM TDR enabled to "false"
Microsoft created some time ago a framework for the creation of nice GUIs in the Windows environment: the Windows Presentation Foundation (WPF). Naturally, they mess up with Nsight, so you have to turn WPF off. It can be done by looking for the DisableWpfHardwareAcceleration.reg file in the "common" directory of Parallel Nsight ("C:\Program Files\NVIDIA Parallel Nsight 1.51\Common" on 32-bit architectures, and "C:\Program Files (x86)\NVIDIA Parallel Nsight 1.51\Common" on 64-bit architectures). Double click on the file to install it.

WPF is not the only thing that breaks Nsight's work: the Aero interface does not allow debugging too. You can disable Aero it by setting a non-Aero theme:

 

Are we done? Not yet! Remember to open the Parallel Nsight Monitor before debugging your kernels. Moreover, if you try compiling a kernel in Visual Studio and debugging it, you could receive a message that basically says that Nsight can't find your executable. You have to explicitly tell where your compiled files are: 

Fill the "Working directory" field with the absolute path to your compiled file.
Now you can enjoy the CUDA debugging features of Parallel Nsight! Yikes!

Wednesday, 1 February 2012

HOWTO fix shared Google calendars not showing up in Android

Google calendar is a simple and useful tool for sharing informations about events and tasks with colleagues. The nice part is that you can gather many calendars and sum them up in a single view. The even nicest part is that everything flows into your android mobile, so you can have a collaborative real-time calendar in your phone.

So, what's the matter? Well, the web-based calendar runs perfectly, but sometimes Android messes up: some calendars, which are correctly shown in Google Calendar, do not appear in Android. Repeating the synchronization does not fix a thing, you have to get dirtier than this.

Go to Settings > Applications > Manage Applications > Running > Calendar storage

Then, click "Clear data" and "Force stop". The first one wipes out the local cache; the latter forces the calendar to restart and download the calendars again from the internet.


A bit messy, but it works.

Wednesday, 18 January 2012

Automated twits from a workstation, using IFTTT

When optimizing parameters of stochastic systems you can have hard time predicting when the process is going to end. It would be nice if the workstation itself warns you when it's done, just like Joshua used to give Lightman a call asking him to keep playing

Hello, Mr. Falken. You are a hard man to reach.
Telephone calls are demodé, anyway. It is much more web 2.0 if the workstation twits you that the jobs are completed and you can check the results out (or something went wrong and you gotta fix the code and so on).

Twitter does offer a RESTful interface for directly twitting stuff around, but handling the authentication takes a lot of work and time (that I don't have, actually). So, I tried something different. Something like this:

Spannometric :) sequence diagram of the system
The key of the process is IFTTT, a nice tool that "[puts] the internet to work for you by creating tasks that fit this simple structure if-this-then-that". In this case, IF "a new message from the workstation is received" THEN "twit the message to @aresio", message that is then forwarded to my Android terminal automatically. IFTTT does a 15' polling, so it's not a real-time thing, but pretty close.

Almost anything was already done, I just glued the pieces together by developing all the stuff on the web server: a simple RESTful interface exposed to the workstation and a plain RSS feed; matter of five minutes, and it works.


Thanks Joshua!