GLTeapot Irregular FPS

[cb88]

On my system GLTeapot usually runs at nearly 300fps.

Currently it is running around 140fps and it will apparently randomly drop to around 70fps. The CPU usage stays around 50% in top all the while so I am not sure what the issue is...I tried chart and it doesn't seem affected. Would some debugging features in the trunk build cause this, I could understand a consistent drop but this seems like a bug?

hrev36930 gcc2hybrid

[stippi]

Most likely caused by your CPU overheating and beginning to drop beats. Is this on a laptop? Please repeat the test after your had your machine turned off for a little while.

[cb88]

This is a K10 laptop. ACPI is disabled...APM is on and I highly doubt that it is overheating since it can get quite hot without downclocking while running Linux though it could be inbuilt thermal protection I *really* doubt this though since it wasn't hot at the time and is fairly well ventilated and the fan has remained on low... I do not believe Haiku supports K8/K10 power management either.

If this is really what is happening it would seem it is not running @ 2Ghz at all but only in the 1.4Ghz and 800Mhz states

Is there a way to determine the current CPU frequency? I just booted it into haiku (after sitting mostly idle on a Linux console) its slightly warm but definitely nothing near where it should be downclocking. I let it set later today and cool off.. and see if that affects it.

[bonefish]

Replying to cb88:

This is a K10 laptop. ACPI is disabled...APM is on and I highly doubt that it is overheating since it can get quite hot without downclocking while running Linux though it could be inbuilt thermal protection I *really* doubt this though since it wasn't hot at the time and is fairly well ventilated and the fan has remained on low... I do not believe Haiku supports K8/K10 power management either.

Note that there are a whole bunch of different power/thermal management mechanisms. Some Intel processors -- I wouldn't be surprised, if AMD implemented something similar (or even the same) -- sport automatic thermal monitoring/protection. The CPU has one or more thermal sensors which when certain (factory-set or software programmed) thresholds are reached cause the CPU to modulate its clock duty cycle (i.e. keep the frequency, but e.g. only work every other tick), reduce the frequency, or even shut down completely. Depending on the processor model some of those mechanisms can be programmed by software, but since Haiku doesn't do any such thing, the CPU's default settings or whatever the BIOS set up will be active when Haiku is running.

If this is really what is happening it would seem it is not running @ 2Ghz at all but only in the 1.4Ghz and 800Mhz states

Is there a way to determine the current CPU frequency?

Nope, at least not for AMD CPUs.

[stargatefan]

my amd k10 core cpu frequency reports properly in pulse.

[phoudoin]

Replying to stargatefan:

my amd k10 core cpu frequency reports properly in pulse.

Pulse call system_info() to get the cpu clock speed. This clock speed is retrieved at kernel startup only. So the reported cpu frequency displayed by Pulse is always the one at kernel startup, even if the current actual have changed since.

[kallisti5]

I should note that after all the Mesa work, the exact same thing still happens. The long term move to a llvmsoftpipe in gcc4 images may fix the issue... however it definitely seems like a cpu throttling issue given the "quick" then "slow" cycle.

If Haiku gets a hardware mouse cursor, double buffering can be enabled (which also may solve the issue).

[pulkomandy]

glteapot now waits for retrace so it will limit itself to the display refresh rate. Is that an acceptable solution?

[cocobean]

Tested on Intel Core and AMD Athlon64 CPUs (hrev54790 x86) with no issues.

NOTE: This is caused by CPU cores throttling and thread switching to the slower cores. You can monitor it through Pulse app for the specific core(s). The earlier AMD K10 (versus 10.5) was known for these issues/features. So, it is not the GLTeapot app. I reviewed steady average FPS (500 FPS) but got zero dips below 450 FPS. Had no issues on older AMD Athlon64 CPU on Haiku R1B1 x86.

[cb88]

Frankly I have no idea why this bug is still open... the "bug" almost certainly was thread swapping and throttling. I agree there. I haven't booted that laptop up in years though I still have it.

Sad to see that 11 years later we are still quibbling over software opengl though.

[pulkomandy]

Thanks for the update. I think we can close this indeed, there is no point in GLTeapot using 100% CPU to render faster than what the screen can display.

[cb88]

I disagree with your latter part, as the WHOLE POINT, of GLTeapot is a smoke test... basically, and syncing it to the display basically makes it useless for that. In fact this weirdness with excessive swappiness and throttling would have been masked by this which is actually undesirable.

GLTeapot is basically "the not a benchmark" that is always used as a benchmark since forever also. It used to be Haiku was about good default choices.. now its about dumbing things down like gnome... /end rant.

[X512]

GLTeapot is basically "the not a benchmark" that is always used as a benchmark since forever also. It used to be Haiku was about good default choices..

GLTeapot use vsync if available. Maybe an option should be added to enable/disable vsync. My ​OpenGLTest2 (execute with make run) can be used for benchmarking.

[rudolfc]

Hi, for what it's worth: I also use(d) GLTeapot for benchmarking (my 3D driver but also with tests concerning AGP and fastwrites i.e.) which is not possible due to the limitation of vsync. It's nice it can sync, but I am all for an option of explicitly -not- doing that.