I was testing the new mapped memory function on a Mac mini with GF 9400M. I found a strange behavior with its “low power” mode.
As discussed here before, we know that GeForce 9400M in a Mac mini runs at 300Mhz when idling. It rises to about 1.1GHz when worked up. However, with my testing program (which does not do any OpenGL rendering at all, just CUDA computation), it failed to go into a “worked up” state. The program is a simple reduction, similar to the sample in the SDK.
The behavior is like this: when I run the program, it runs relatively slow (at about 1.768GB/s in terms of memory bandwidth). I timed the kernel with clock() inside the kernel and wall clock (the system clock() function), both results are similar, at around 150ms processing 256MB data. It remains the same in consecutive runs. However, if I run an OpenGL program then close it (for example, the fluidGL sample in the SDK), and then run my program immediately, my program runs faster, about 42 ms (~ 6.3GB/s). Curiously, the clocks counted in the kernel is about the same (around 46 million cycles). That means my program is not able to put the chip out of the idling mode, but an OpenGL program is able to do so.
So my question is, what is a fool proof way to put the chip out of “idling” mode? Since I rarely need to use OpenGL to visualize my results, I don’t really want to run a OpenGL rendering just to make sure the chip is running at full speed.