Imagine this piece of code:
1
2
3
4
5
6
7
|
while(true)
{
glCallList(x);
Display.update();
}
|
Because the display-list is huge, the framerate is rather low (10fps). Both the glCallList() and update() are blocking big-time, which is to be expected.
For me this results in CPU-usage of 100% while the CPU should be doing basicly nothing. I would be able to understand it, if OpenGL-drivers or LWJGL were yield()ing while waiting for the GPU to finish the operation, so I made a testcase to check if this was the case: I launch a thread which is burning all available cpu-cycles:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
while(true)
{
long t0 = System.nanoTime();
final int count = 32 * 1024 * 1024;
double value = 0.0;
for (int i = 0; i < count; i++)
{
value = Math.sqrt(value) + i;
}
long t1 = System.nanoTime();
System.out.println("took: " + ((t1 - t0)/1000000) + "ms (value=" + value + ")");
}
|
Below follows a table with performance data for both threads. If there is a "-" that means that thread is not started.
1
2
3
4
5
| Render Thread Math Thread
Case A: 10FPS thus 100% cpu - thus 0% cpu
Case B: - thus 0% cpu 1200ms thus 100% cpu
Case C: 10FPS thus 50% cpu 2400ms thus 50% cpu* |
In "Case C" both threads are running. Because the Math Thread takes twice as long in "Case C" as in "Case B" I conclude it gets half of the cpu-cycles, explaining the percentages in "Case C".
Hm...
So this all boils down to:
why are 50% of the cpu-cyles consumed (not idle, not yielding) while blocking on the 2 methods in the Render Thread?~~
On a side-note. From the table you can also conclude that if the Render Thread is the only running thread, it's yielding 50% it' time, and actually doing *something* 50% of its time - as it can giveup only 50% of it's time to the Math Thread while maintaining it's framerate.
