glGenerateMipmap corruption after hibernate

Hi,
I’m a developer at Wube Software, working on Factorio (https://www.factorio.com/).
I noticed today that there is an issue with mipmaps in opengl when resuming from hibernation.
When using mipmaps generated with glGenerateMipmap, if you hibernate and resume, the mipmap data will be corrupted.
The base texture is unaffected.
This corruption will not happen if you use explicit mipmap data instead of glGenerateMipmap.
I am running the latest drivers from your website (not distro-provided ones), version 390.77 on a GTX 980.
I also had the same issue when running distro-provided drivers (version 384.130).
Distro is debian stretch, kernel version is 4.9.0.
If needs be we can probably send you a development version to use in debugging, or you can use a simple test case I will attach.

Steps to reproduce:

  1. Compile and run my test program, build instructions in attached readme.txt.
  2. Zoom in and out using arrow up and down, verify that the cube retains a consistent texture of a coloured number on a white background.
  3. Leaving the sample running, hibernate your machine (sudo pm-hibernate, or use the gui).
  4. Resume, and zoom in and out again. When zoomed in, the cube will render correctly, but when zoomed out to the point that mipmapping begins, the texture will appear corrupted (light grey for me).

The readme also has instructions to load a DDS file with precomputed mipmaps, which will not exhibit the bug.

I have attached a zip of the sample code, and some video of the sample running on my machine, both before and after hibernation.
I have also attached output from your bug reporting script.
nvidia-bug-report.log.gz (140 KB)
sample_code.zip (106 KB)
videos.zip (138 KB)

Might be connected with this:
https://www.khronos.org/registry/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt

When I use GetGraphicsResetStatusARB from ARB_robustness, with GLX_CONTEXT_RESET_NOTIFICATION_STRATEGY_ARB set to GLX_LOSE_CONTEXT_ON_RESET_ARB, I don’t get a reset event on hibernate.
When I use NV_robustness_video_memory_purge as well, I do get a PURGED_CONTEXT_RESET_NV event, but I get that for all sorts of things (like switching vt) that were previously fine.

IMO, I should get an UNKNOWN_CONTEXT_RESET_ARB event when using ARB_robustness without NV_robustness_video_memory_purge, but only when I’ve actually lost some resources, not just when any event occurs that could lead to resource loss sometimes.
Does the current driver architecture allow this?

Also, the extension description says that NV_robustness_video_memory_purge should be temporary, but was published in 2016, and is still exposed by modern drivers. Is there any update on the status of this?
Is it still being worked on, or has this situation become permanent?

Yeah, this is nice indeed:

What’s a limited lifespan? It has been more than two years…

It’s expected to get a PURGED_CONTEXT_RESET_NV event on VT switches, due to the current driver architecture. While they’re less likely to result in corrupt data than suspend or hibernate, it’s not guaranteed that they won’t.

I apologize about the ongoing need for NV_robustness_video_memory_purge. Fixing it is a very involved design change in the driver and we want to avoid introducing any performance or functionality regressions.