I am developing a code in CUDA, but I am wondering at which time the kernel developed goes onto device's global Memory?
Is it at compilation or during execution ?
If you compile a code using nvcc, that has no effect on any GPUs installed in the machine, and in fact may be done on a machine with no GPUs.
Any kernels to be loaded by a program will be loaded onto the GPU after that program begins execution.
Related
I managed to get Theano working with either GPU or multicore CPU on Ubuntu 14.04 by following this tutorial.
First I got multicore working (I could verify that in System Monitor).
Then, after adding the config below to .theanorc, I got GPU working:
[global]
device = gpu
floatX = float32
I verified it by running the test from the tutorial and checking the execution times, and also by the log message when running my program:
"Using gpu device 0: GeForce GT 525M"
But as soon as GPU started working I wouldn't see multicore in System Monitor anymore. It uses just one core at 100% like before.
How can I use both? Is it even possible?
You can't fully utilize both multicore and GPU at the same time.
Maybe this can be impoved in the future.
Is it possible to compile a CUDA program without having a CUDA capable device on the same node, using only NVIDIA CUDA Toolkit...?
The answer to your question is YES.
The nvcc compiler driver is not related to the physical presence of a device, so you can compile CUDA codes even without a CUDA capable GPU. Be warned however that, as remarked by Robert Crovella, the CUDA driver library libcuda.so (cuda.lib for Windows) comes with the NVIDIA driver and not with the CUDA toolkit installer. This means that codes requiring driver APIs (whose entry points are prefixed with cu, see Appendix H of the CUDA C Programming Guide) will need a forced installation of a "recent" driver without the presence of an NVIDIA GPU, running the driver installer separately with the --help command line switch.
Following the same rationale, you can compile CUDA codes for an architecture when your node hosts a GPU of a different architecture. For example, you can compile a code for a GeForce GT 540M (compute capability 2.1) on a machine hosting a GT 210 (compute capability 1.2).
Of course, in both the cases (no GPU or GPU with different architecture), you will not be able to successfully run the code.
For the early versions of CUDA, it was possible to compile the code under an emulation modality and run the compiled code on a CPU, but device emulation is since some time deprecated. If you don't have a CUDA capable device, but want to run CUDA codes you can try using gpuocelot (but I don't have any experience with that).
I would like to know how the allocation of a memory space in CUDA is implemented under Ubuntu Linux. In other words, how cudaMalloc() works internally under Ubuntu Linux? What are the system calls used for this function?
CUDA is proprietary. It's likely that CUDA driver implementation is the same or similar to OpenCL.
But while OpenCL specification is open the implementation is not necessary and NVIDIA OpenCL driver isn’t open .
It's possible that the implementation is as simple as the driver submitting a malloc command completely handled on the hardware side with the kernel driver communicating with the system to achieve unified virtual addressing and to determine what memory resides in VRAM. Probably the technical part at the software side is to avoid the allocation or defer it.
Looking into pocl can give you some idea how things can look like. NVIDIA implementation can be very different though.
Does anyone know if its possible to Debug CUDA using parallel NSight on a remote machine? I am able to step into CUDA code but not my host code. It says CUDA has the capability to generate host debug information so debugging remotely and locally should be possible.
My card is a 580 GTX.
//device code <-- able to debug device code
//host code <---- when device code returns, should be able to debug host code
Thanks!
Simultaneous GPU/CPU debugging from a single IDE instance is unfortunately not possible with the current releases of Nsight and Visual Studio.
As a workaround, you can start GPU debugging from one copy of Visual Studio, then open a second IDE instance and attach its CPU debugger. They won't have unified stepping, but you can at least set breakpoints independently.
It should now be possible to attach both the Visual Studio default debugger and NSight in the same VS instance. Then this should work.
What does Nvidia CUDA driver do exactly? from the perspective of using CUDA.
The driver passes the kernel code, with the execution configuration (#threads, #blocks)...
and what else?
I saw some post that the driver should be aware of the number of available SMs.
But isn't that unnecessary ? Once the kernel is passed to GPU, the GPU scheduler just needs to spread the work to available SMs...
The GPU isn't a fully autonomous device, it requires a lot of help from the host driver to do even
the simplest things. As I understand it the driver contains at least:
JIT compiler/optimizer (PTX assembly code can be compiled by the driver at runtime, the driver will also recompile code to match the execution architecture of the device if required and possible)
Device memory management
Host memory management (DMA transfer buffers, pinned and mapped host memory, unified addressing model)
Context and runtime support (so code/heap/stack/printf buffer memory management), dynamic symbol management, streams, etc
Kernel "grid level" scheduler (includes managing multiple simultaneous kernels on architectures that support it)
Compute mode management
Display driver interop (for DirectX and OpenGL resource sharing)
That probably represents the bare minimum that is required to get some userland device code onto a GPU and running via the host side APIs.