Hi,

I'm using Windows 10 and Visual Studio 2022 and C++17 with the multi-threaded MSVC Runtime as a DLL (/MDd and /MD). I'm using glfw3.3.7, glad (latest version as of 6/12/2022), and GLM 0.9.9.9.

I downloaded GLFW3 and created the test program from their quick start page. I substituted GLM in for linmath. The test program is just the standard early test thing that shows a spinning triangle.

While I was running it, my computer crashed! Out of nowhere! And when I restarted it, it went into the bios with a message saying my CPU was at a high temperature. My fans had not even kicked in! It was like somehow my computer didn't notice it was overheating!

I've turned down my overclocking and tuned my fan profile so this isn't happening as quickly, now, but the strange thing is, this program isn't causing high cpu usage at all! The cpu is sitting around at about 4% usage! (I have glfwSwapInterval(1) set.) And yet I can watch the “CPU package” temperature rising in Amory Crate! The “CPU” temperature doesn't rise so much, so the fans don't spin up, I have to manually turn up the fan speed to prevent it from overheating!

What the freak!? No game I play does this. I have an AMD5900x with a Nvidia 3060 gpu. All my off-the-shelf games run great, I can overclock, no problem. Cpu and gpu temps stay low all the time. There's something specific about This Particular Program that somehow heats up the cpu WITHOUT causing high cpu usage! This is so strange!

It can't possibly be GLM? Is it something about memory bus thrashing because of the MS _security shtuff doing extra work for every buffer?

I dunno. Grasping at straws here. I'll try compiling in release mode (as opposed to debug mode), I know GLM is a lot more efficient in the release version. I'll make sure the release version is compiling with GS-. I'll try doing a few optimizations like taking the glViewport statement out of the main render loop. But..? Really? My “CPU Package” is overheating without showing high usage? And it doesn't happen with any of my games, only with this particular OpenGL program? That's not even doing much? What could possibly be happening here?

Any ideas?

edit: I just noticed my “cpu package” temp, as displayed by Amory Crate, jumps up from like 62 to 69(!) on the very next sample after I shut off my test program. So it's like somehow my test program is preventing Amory Crate from properly sampling the cpu package temp. What? How could it possibly be doing that?

Hello and thanks for your replies,.

I'm reluctant to mess with the cooler because I already tried pretty hard to do the best job I could of dealing with the cold plate and the thermal paste and so on and I have no trouble with other programs, I'm even able to overclock pretty well, I just have trouble with this program.

I did play around with setting various values with glSetSwapInterval and just putting a direct sleep in using std::chrono's high resolution clock and sleep_until function.

I found that cranking up swap interval value causes really bad jittering and reduces the cpu package temp some, but only by a few degrees.

I found that setting swap interval to 0, and instead adding in a deliberate sleep actually smooths the jittering in comparison with using swapInterval(0) and no sleep. On this computer, with no swap interval and no sleep, I still don't see any noticeable cpu usage. I'm wondering if maybe my driver settings are forcing a vsync.

BUT I found that using swap interval 0 and using a deliberate sleep value reduces the resulting package temp by almost 15 degrees! It's still hardly touching the CPU in terms of over all usage. The CPU usage stays between 1% at about 3% whether my program is running or not.

Wow. So weird. Well, thanks for the suggestions. I guess I'll work on getting an fps value displayed and on letting user maybe select a target fps value and then I'll have the program slowly adjust the sleep amount to try to average about that fps, given however long my frame update is taking on their box. (If they enter an impossible target, I'll just set the sleep to 0.) Maybe I'll but in a “vertical sync” option which would toggle the glSwapInterval value between 0 and 1.

Even just a sleep of 500 nanoseconds reduces the resulting temp by over 10 degrees.