As computer systems have advanced, graphics processing units (GPUs) have become increasingly advanced both in complexity and computing power. As a result of this increase in processing power, GPUs are now capable of executing both graphics processing and more general computing tasks.
The ability to execute general computing tasks on a GPU has lead to increased development of programs that execute general computing tasks on a GPU and the corresponding need to be able to debug tasks executing on the GPU. A GPGPU program executing general computing tasks on a GPU has a host portion executing on a central processing unit (CPU) and a device portion executing on the GPU. With conventional solutions, it is not possible to access data for debugging of both the host or CPU side of the program and the device or GPU side of an already executing GPGPU program.
Conventional solutions can provide access to the device or GPU portion of the GPGPU program if the GPGPU program is started from within a debugger. Unfortunately, starting the program within the debugger affects the program's behavior because of state collection during the execution of the CPU and GPU sides of the GPGPU program. The impact of starting the program within the debugger thus makes bugs that depend on a particular order of thread execution, known as race conditions, potentially unobservable. This can make debugging particularly challenging. Further, executing the GPGPU program within the debugger negatively impact performances and slows execution of the program.