CTRL+C Exit Causes Display Driver Reset on Windows about nextpnr

[q3k]

Could you record an apitrace of GL calls?

[cr1901]

Since this morning, I am no longer able to consistently crash the driver, even when using the same commit as earlier. I have an API trace of an instance where the display driver crashes, but replaying the trace does not cause a crash it seems. File is too big to upload to Github, so: https://www.dropbox.com/s/k550dm4idav8a80/nextpnr-ice40.1.trace.zip?dl=0

[mmicko]

Now there is a proper handling of Ctrl-C for windows. Managed to get it crash (not OpenGL related crash on my side) in debug MSVC build on each CTRL-C. With handler now it sends proper application close.
Please check if #13 helps in your case as well

[mmicko]

@cr1901 can you please confirm if this fixes your issue ?

[cr1901]

@mmicko I am still able to duplicate the crash using the steps above:

William@William-THINK MINGW64 ~
$ nextpnr-ice40 -V
nextpnr-ice40 -- Next Generation Place and Route (git sha1 e7fe046)

[datenwolf]

TL;DR: I have a few ideas on how to address the issue, but doing so I'd like to refactor some of the code, specifically move the majority of the stuff in FPGAViewWidget into a dedicated worker (either a class, or just a namespace – technically it should be just a bunch of functions). However I'd like to avoid writing a bunch of stuff that then collides with a different merge. If there's someone working on the OpenGL code, please coordinate with me, to avoid extra work later on.

Alright I took a quick glimpse over the code and on the circumstance of the issue. The issue at hand is, that this driver crash happens in a Optimus environment, which means, that it goes through driver codepaths that are brittle like ill tempered glass and the way Qt5 manages OpenGL is questionable (I could go on a lengthy rant about this, but let's not digress; still better than GTK+ though).

Toolkit integration (no matter if GTK, Qt or whatever) has always been a sore point, because most toolkit developers write their code against the OpenGL reference pages instead of the specification and quite a few parts of the OpenGL reference pages actually contradict the normative specification. This is a well known fact among 3D and game engine programmers, but not so well known outside of these circles, it seems.

Anyway, the result is, that Qt does some things with OpenGL which are actually suboptimal in a "pure" (i.e. single driver, single kind of GPU) environment, but blow up in your face, if your program happens to work with a mixture of on-screen and off-screen surfaces (which Qt5 internally does) and windows get dynamically pushed between GPUs in response to deferred use of some OpenGL feature.

One way to deal with this is to simply force the use of the NVidia GPU no matter what, by defining the following symbol in the executable

extern "C" {
     _declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
}

However the tedious but "we're nice to the user and conservative about the use of resources" approach would be to take matters in "our own" hands and manage our own windowless OpenGL context, which rendering results we then transfer to the window. I hear you ask "you want to bit blit each frame?" and I say, "yes", and you ask "isn't that inefficient?" and I say "that's what happening behind the scenes in Optimus anyway, but through a DMA-able shared memory fastpath".

Not using a QOpenGLWidget is the only way to prevent Qt from internally creating a bunch of off-screen buffers and somewhat reliably limit it to using only a single OpenGL context. Little known fact, especially toolkit writers seem ignorant about it: One can freely mix and match drawables and OpenGL contexts, as long as their pixelformats/visuals are compatible, so you can use a single OpenGL context for all your different windows; child, popup, top-level, embedded/reparented, doesn't matter. Unfortunately Qt (and GTK) creates a own OpenGL context for each QOpenGLWidget and establishes list sharing among the backend renderer contexts. This is something that really tends to blow up drivers, if one misses to glUnmapBuffers, or if there are rendering commands in flight while a context is forcibly torn down.

I already did this work (work around Qt's OpenGL stuff) once; unfortunately this work was under contract and I'll have to redo it; in retrospect some things I can do cleaner anyway.

That would be the plan: Refactor FPGAViewWidget so that the drawing code therein is no longer tied to the widget code (ideally just pure OpenGL), create a OpenGL context independently from Qt through direct use of WGL/GLX. Doing it with GLX is straightforward, no need to jump hoops and all the WGL hoop jumping I already implemented in https://github.com/datenwolf/wglarb and use https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_gpu_affinity.txt to determine if there is a dedicated NVidia GPU around, and appropriately select this.

---

Of course there's another option: Use Vulkan instead of OpenGL. For all its verbosity and the extra legwork required, the mere fact that multi GPU scenarios are cleanly addressed in the API and a clear interface between windowing environments, GPU contexts and logical GPUs has been defined in Vulkan makes the whole API much more attractive. I'm just putting that up for discussion here.