A really pointless and stupid question has been bugging me...

When a kernel is running for a large (>1s) period of time, i can still move my mouse and see the cursor move on the screen. I cant click anything, but what is it that is rendering my cursor on the screen if the video card is busy with a cuda kernel?

See… pointless!

Actually the resources are shared between CUDA calculations and the graphics tasks, I suspect in favor of the second. Sometimes under heavy CUDA load it becomes really hard to interact with my mouse and I can feel that GPU being under a load. Also, under high resolutions the available memory to CUDA decreases significantly.

So, what happens to the shared-memory cotents when the context-switch happens???

Graphics tasks dont use shared memory for rendering or whatever??? Hmm…

btw,

Aileur, How do you know that your mouse moved exactly when your CUDA kernel was running?? Since your kernel runs just for 1 second, it is difficult to trakc (even if u launch repeatedly…)

Most CUDA kernel hangs – will hand the Video driver as well until the 5-sec watchdog come to your rescue…

So,

I dont think Graphics and CUDA kernels are context-switched (though they both share the same hardware)

Your GPU has hardware cursor support, which basically means that the blitting of the cursor doesn’t depend on updates of the front-buffer.
This is why in many games, the cursor stays smooth, even if the frame rate drops. Cool little thing, that.

But CUDA is a completely different compute mode on the GPU. There is a context switch that happens when a CUDA kernel activates and when it does not even the mouse cursor will move until that kernel completes.

But to answer Sarnaths concerns, the context switch back to graphics mode only happens after a kernel completes so there are no issues when shared memory or the like.

Thanks for the answer. THat is what I had in mind as well. The context switch that you mention happens when you launch the kernel and after that it goes un-interrupted and then the context is restored back once the kernel is done.

So, during kernel execution,the Kernel is the King.

Beware of autocratic Kings who dont want to relinquish power. They can hang your display.

But NVIDIA’s constitution allows for a 5-sec watchdog to save you from such fellas…

I put 1s as a lower bound, i have kernels that run for 5-10 seconds. Or even a moving cursor right until the PC bluescreened from a watchdog problem.

One of my teacher told me that in X (which im not using, im in windows) only what is actually 3d accelerated (say, a glxgears window) will come out of the “accelerating” part of the GPU while normal blitting, if the rest of the window, if not updated, will continue to display, which is the phenomenom we re seeing.
Still doesnt explain the fact that my cursor is moving… or is it just me?

What TB said is pretty interesting, im looking into that right now.

Time to check your kernel, error etc… :-)

Interesting stuff. From what im reading, this “hardware cursor” only kicks in when in a “game”… so i guess when the GPU is being used.

In vista with AERO, its a hardware cursor since the desktop is 3d accelerated (im not using vista, im using windows xp)

So i guess a kernel running is assumed to be something “3d accelerated”, which could explain it all.

Well, on my Linux box, there is no time during the execution of a several seconds long kernel where the cursor freezes. And X is using the hardware cursor, AFAIK.

But as always, when it comes to driver internals, your guess is as good as mine. ;)

Odd, on my linux box there is… I guess we’ve proven that you cannot rely on the movment of the cursor to tell if the GPU is in compute mode or not.

Hmm, on my MacBook you feel when the CUDA kicks in, as even mouse pointer starts to move slower…

Pretty sure this question is dramatically more complicated than any of you realize…

Well Tim, then tell us and we’ll tell you if it matches our expectation of complexity. ;)