Video Card Bugs

[SirDamnALot]

Would you try selecting a planet in game then hitting ctrl+Y. That should jump you into a test screen that shows only a rendering of the selected planet. If the planet shader is causing excessive load on your card, the gpu stats while this screen is open would prove it. (Note that different planets may have varying shader costs, a ringed world, like Tendao or Rastaban II, is probably a good "worst case" test.)

Bingo! Showing my starting planet (big blue world) in all its glory, ramps up the GPU load and temperature.
Then I switched to fullscreen but saw not much increase. Wanted go back to windowed with Ctrl+Esc and the whole system crashed
I try to reproduce that, maybe just a fluke (not the first time the AMD driver randomly drags the whole OS into the abyss)

Edit: yeah, that was a fluke. Crash did not happen again
Updated my Driver to the latest version (which I lag behind, because it causes my display link devices in my cockpit to act up, until they adapt their drivers again)
Still high (up to 100%) workload while looking at nicely rendered planets =)

Edit2:
I played with the new drivers setting a bit.
Here is the funny thing: If I enforce vsync in the driver, the load in fullscreen mode goes next to nothing (like rest of the game).
In window mode (where vsync don't do anything) it goes up again. (Target frame rate in driver does nothing)

[sven]

Here is the funny thing: If I enforce vsync in the driver, the load in fullscreen mode goes next to nothing (like rest of the game).
In window mode (where vsync don't do anything) it goes up again. (Target frame rate in driver does nothing)

Interesting. If you hit ctrl+h when the start screen is up, you should see an fps display. Does the fps number change depending on whether you have vsync enabled? (On my machine the fps never goes above 60, but, if you are going above 60 in some modes, that could explain a lot.)

[SirDamnALot]

Ok, I think we struck gold

frames.png (6.04 KiB) Viewed 93013 times

With Vsync off, the main menu and the dev planet view goes completly off the rails.
With Vsync on, in windowed mode on main menu and dev view, the fps are nailed to 144 fps, my monitor refresh rate.
But I suspect that there are still crazy many frames rendered, but discarded to match the desktop refresh rate.

Edit: maybe some other forum regulars could also try this ? Would be good to see if that is reproducible or only happens to a few.

[sven]

With Vsync off, the main menu and the dev planet view goes completly off the rails.
With Vsync on, in windowed mode on main menu and dev view, the fps are nailed to 144 fps, my monitor refresh rate.
But I suspect that there are still crazy many frames rendered, but discarded to match the desktop refresh rate.

Oh wow. A reported FPS of 2000! No wonder your GPU load is going nuts. Even on a monitor with a 144 max referesh rate, I really don't think we should need to be redrawing more than 60 times a second. There are some tools I should be able to use to cap out the framerate (including but not limited to enabling vsync via a driver hook). I'll need to look into that. Many thanks

[sven]

With Vsync off, the main menu and the dev planet view goes completly off the rails.
With Vsync on, in windowed mode on main menu and dev view, the fps are nailed to 144 fps, my monitor refresh rate.
But I suspect that there are still crazy many frames rendered, but discarded to match the desktop refresh rate.

Oh wow. A reported FPS of 2000! No wonder your GPU load is going nuts. Even on a monitor with a 144 max referesh rate, I really don't think we should need to be redrawing more than 60 times a second. There are some tools I should be able to use to cap out the framerate (including but not limited to enabling vsync via a driver hook). I'll need to look into that. Many thanks

Ok, as of the current 'dev' build (r14991) the game should not attempt to draw frames faster than your monitor can render them. Let me know if you're still able to generate absurd FPS numbers with the latest 'dev' binaries. Thanks again

[SirDamnALot]

Sounds great, I'll try to do a test run this evening =)

[SirDamnALot]

Ok, as of the current 'dev' build (r14991) the game should not attempt to draw frames faster than your monitor can render them. Let me know if you're still able to generate absurd FPS numbers with the latest 'dev' binaries. Thanks again

I am now on r14997 dev (03/17/16), but sorry to say that the FPS are still running wild.
Same picture as before.
(But the Planet renaming works, Thanks! =) )

Edit: Ugh, I just had a dimly lit lightbulb appear over my head... Does you fix work with vsync ? For the vsync=off test, I disabled vsync in the driver. Even if the game wanted to use it. Have to redo it later with "soft-off" to be sure. Also I have a windows 10 laptop, I'll test there too, to get a second opinion

[sven]

For the vsync=off test, I disabled vsync in the driver. Even if the game wanted to use it. Have to redo it later with "soft-off" to be sure. Also I have a windows 10 laptop, I'll test there too, to get a second opinion

Yes, the current dev build should be asking the driver to do something that it might reasonably interpret as "enabling vsync". If you've got vsync set to a "hard off" that could interfere with the FPS limiting. Thanks again.

[SirDamnALot]

I got a fresh batch of test runs

Unbenannt3.png (5.94 KiB) Viewed 92985 times

The fullscreen department is now under control, regardless if vsync is enforced by the driver.
(Caveat: the driver allows vsync in the first place, but that is outside your control)

In windowed mode, the frame rate is shown as capping out on the monitor refresh rate, but still got a high (99-100%) GPU load.
Interesting is, that this now also happens on the galaxy map, which behaved previously normaly for vsync=on.

[sven]

I got a fresh batch of test runs

Interesting is, that this now also happens on the galaxy map, which behaved previously normaly for vsync=on.

There's a lot of variables that impact the fps. Basically, we're doing at least 3 importantly different things more or less in parallel while drawing the galaxy map:*

1) Executing various Lua scripts that define the UI behaviors. (This is a load on your CPU.)
2) Drawing stuff. (This is a load on your GPU.)
3) Moving assorted rending commands and data to the GPU. (This is a load on your PCI-Express bus.)

Depending on your machine, and just what's going on on your map, any one of those items might end up being the bottleneck that caps FPS.

* (If we're going to get really technical about it, this is an oversimplification, as you can further break down the CPU and GPU loads into speed hits from memory access costs vs. compute costs -- and those ratios also vary depending on what exactly you're doing.)

The reason the un-vsynced Planet View FPS are so high, (and also the reason that the GPU load goes nuts), is probably that there's basically no CPU or bus load in this screen -- so there's no other potential bottleneck to slow things down.

The Galaxy Map screen has higher CPU / bus needs, so there's more variables in play there than just the max GPU rendering speed. But, on a screen with more discovered systems, or more colonized planets, the CPU load vs. GPU load ratio might vary, which will change the degree to which the CPU load is acting to throttle your FPS

Um. Moral of the story: Even with vsync your machine is probably still encountering situations where your GPU is being abused more than it really needs to be -- 144 FPS is unnecessarily high. On setups with such high monitor refresh rates, I could tell the driver to vsync every 2 refresh cycles, rather, so your fps would be capped at 72 -- which is probably a good idea in your case. But, that logic is also a little more complicated to code up. (And then I'd need to think about just how to handle situations where you have 1 60 Hertz monitor, and one 144 Hertz monitor, and somehow move the window between them ).

Edit: A simpler fix is probably just to include another throttling mechanism -- like a high-res timer that prevents the FPS from going much over 70.

[SirDamnALot]

Edit: A simpler fix is probably just to include another throttling mechanism -- like a high-res timer that prevents the FPS from going much over 70.

Thanks for the explanation, peekig under the hood of an engine is always fascinating =) Even if I understand only the simplified version
Measuring the render timings and paceing yourself to hit a desired framerate is probably the safest way to ensure a low performance load.
But that opens the problems of predicting the complexity of the render tasks and
comes with it own set of problems (stuttering, rubberbanding, etc).
On the plus side, when you can freely set an fps cap, you could give low spec systems an option
to cap out even lower on fps (thinking of laptops and tablets with limited power supply).

[mharmless]

I just realized that the white-triangle-flickering on the production selection screen that I previously saw did not manifest at all during that 2.5 hours of recording. So looks like that is maybe squished.

[sven]

I just realized that the white-triangle-flickering on the production selection screen that I previously saw did not manifest at all during that 2.5 hours of recording. So looks like that is maybe squished.

Interesting. There's a small chance that the changes I made in response to SirDamnALot's GPU load issues (essentially enabling vsync by default) might have had the side effect of fixing the problem. That may be too much to reasonably hope though

Let me know if you notice the flickering recur.

[mharmless]

I just realized that the white-triangle-flickering on the production selection screen that I previously saw did not manifest at all during that 2.5 hours of recording. So looks like that is maybe squished.

Interesting. There's a small chance that the changes I made in response to SirDamnALot's GPU load issues (essentially enabling vsync by default) might have had the side effect of fixing the problem. That may be too much to reasonably hope though

Let me know if you notice the flickering recur.

This flickering is back in this build. Didn't notice it at all playing with projector and home media PC, but it was back in force on my primary gaming PC. i7-4770, 16gb ram, Windows 10 x64, 480gb SSD, Radeon HD 7870 with driver 16.300.2311.0 supplied by AMD on July 18th, 2016.

I just recorded 36 minutes of play to capture this, first flicker happens just after 18 minutes and then there are a few more in the remaining 18 minutes. You can also see the bombardment slowdown/speedup graphical effect that I haven't filed as a separate bug. It's a little jarring because the altered motion draws my eyes away from the bombard screen and to the background map. Video should be live in ten minutes or so according to youtube.

[Krax]

Hi! Sorry for reviving this old post. I have at work´s computer an old Gforce 9500GT. The game wont launch. It gives the blue screen of death and says "Attempt to reset display driver and recover from time out" and then restarts the computer. I put an image taken from internet but mine is the same. All other steam games works OK. Any Ideas? I already put several drivers and upgraded to the last version.