Closed ghost closed 8 years ago
This is what I started with initially when rewriting the rendering engine in OpenGL 3. However, since I had a lot of problems with incorrect rendering (both due to different applications not resetting their OpenGL state and fonts being a pain in the ass) as it is, I stripped down the codebase during development to a bare minimum.
I always wanted to do this, but I never had the time or motivation. Unfortunately, it's unlikely that I will be able to find enough time in the next few months.
This is a big issue for a benchmark tool, I believe. It should have almost 0 impact on the performance, otherwise it can't serve as a benchmark tool. I measured this in a simple game Cogs. I just let it spin in the game menu and in the first level, it gives absolutely consistent FPS. This is what I see:
Tool | Game menu FPS | Game FPS |
---|---|---|
steam overlay | 193 | 88 |
voglperf | 192 | 86 |
glxosd default (31 lines) | 143 | 68 |
glxosd trimmed (16 lines) | 149 | 69 |
glxosd fps only (1 line) | 164 | 73 |
The FPS drop is huge, when compared to steam overlay or voglperf. The more lines rendered, the worse. Unfortunately, glxosd prints a lot of lines by default (whole libsensors output, including empty lines #67, 31 lines in my case). Even if I print just a single FPS line, the drop is still very significant. If I disable printing output, and set frame_logging_message_string
to empty (so that nothing is printed) and start recording, I get a few extra fps, but I do no come close to steam overlay or voglperf. So this is not just about text rendering, something else is making it slow. But it would be nice to start the optimizations with the text rendering, because every extra character takes a big toll on the overall performance. And Linux is getting a lot of bad press for slow gaming performance, but people simply assume that the benchmarking tools have negligible impact. glxosd is popular, could you please have a look into this? Thanks a lot.
So, quite interestingly, this does not affect all games. I've tried other games, and in many of them I see no performance degradation at all. However, I found another case with Bastion:
Tool | Game menu FPS | Game FPS |
---|---|---|
steam overlay | 1850 | 770 |
glxosd trimmed (16 lines) | 700 | 570 |
glxosd fps only (1 line) | 1270 | 750 |
I can't say exactly why this affects some games and not some others, but my guess is that it could be related whether the game is CPU-bound or not. It seems to me that glxosd does not degrade graphical performance, but the text rendering computation is very slow. And therefore for CPU-bound games, this results in drop in FPS, while for GPU-bound game this does not. But that's just my theory. It can also somehow be related to how the games use OpenGL, which I have no experience with.
I am currently testing efficient text rendering with version 3. Thank you very much for providing very useful test cases.
GLXOSD v3 has the following performance improvements related to text rendering:
Therefore, I think it's safe to close this issue. If you still think that this isn't enough, please let me know.
GLXOSD's overlay uses a separate batch/texture for each glyph, which is inefficient. A better way to render text is to pack all glyphs you need into one texture, then use texture coordinates to select glyphs for rendering.
I tested the FPS impact of GLXOSD on a mostly empty room being rendered in OpenMW:
GLXOSD off: 700 fps GLXOSD on: 650 fps
That's a difference of 0.1ms. I guess you could say that's almost negligible, but the situation may be different with a lower end video card. Also, GLXOSD is a benchmarking tool after all, so capturing the FPS as precisely as possible would be appreciated :)
Related to bug #37, which might also benefit from a text rendering rewrite.