Hello, I am trying to run a simple Qt 5 sample application (namely QtHelloGL) in NSight 2019.1. I have disabled the binary shader cache (via environment variable QT_DISABLE_SHADER_DISK_CACHE) so that the shader programs can be dynamically edited and recompiled in NSight’s DSE.
However, when I attempt to edit and compile any shader program, NSight generates “Compile error: Internal error.” No other information is provided; it simply fails. Even if I recompile the shader as-is - without any edits - the result is the same.
The problem seems unique to this Qt sample but may extend to Qt/GL projects in general (other non-Qt sample applications do not exhibit this problem). The only thing I can think of is that QtOpenGLWidget renders to an offscreen FBO using its own private context (separate from the global application context) and that NSight doesn’t like/support this (which would be very limiting if such is the case). When I break into a capture and attempt to edit the shader in the DSE, I am in the private context of the QtOpenGLWidget, not the one created for the top-level window, and perhaps this is an issue for NSight. But this is only a guess.
Is there any way to get any information out of NSight regarding the nature of this “internal compiler error”?
UPDATE: It doesn’t really seem to matter which context I am in, I can select draw events in either context from the Scrubber and recompiling shaders in either context yields this error. NSight for Visual Studio also produces a similar output:
Error encountered while compiling the dseShader.
Please refer to the “NSight” output window for more details.
Shader 6000000100000003 3 failed compilation with the following error:
C:\Users\xxxxxxxxxx\AppData\Local\Temp\shader-6000000100000003 3-Vertex-EB9812E4.glsl error: Internal error.
I have reproduced this on two different machines, both locally and via remote debugging. I have also reproduced this bug in versions going back to NSight 5.6 (I did not test earlier versions before this). It is something unique to the application.
Thanks,
J
Hi J,
Sorry that you are running into this issue!
We actually just fixed a couple issues related to Qt5 applications. Those fixes will be available in our next release in a couple of weeks.
Although, I think this may be a different issue.
Could you provide your target configuration? (OS, Driver version, GPU version, etc.)
Also, just to confirm, you are using Nsight Graphics, not Nsight Visual Studio Edition?
Thanks,
Seth
Hi Seth,
Running both Nsight Graphics and Nsight Visual Studio Edition and have reproduced the problem in BOTH products.
Nsight Graphics emits:
Compiling…
Compile error: Internal error.
Nsight Visual Studio emits:
Error encountered while compiling the dseShader.
Please refer to the “NSight” output window for more details.
Shader 6000000100000003 3 failed compilation with the following error:
C:\Users\xxxxxxxxxx\AppData\Local\Temp\shader-6000000100000003 3-Vertex-EB9812E4.glsl error: Internal error.
We have been running v1.2(Gfx)/5.6(VS) for the past year but recently moved to the latest version 2019.1 in hopes this issue may have been addressed already (it has not). I have reproduced this on three different systems running Windows 10 (version 1809) Pro and Windows 8.1 Pro. One system has GTX 1080 (Pascal), one a GTX 1050 Ti, and another a GT 730 (Kepler). I believe the driver version on all these systems is 397.93. It reproduces debugging locally or remotely. We first experienced this issue in our Qt 5.10.1 application, then reproduced it using the OpenGL sample QtHelloGL that ships with Qt 5. The common denominator seems to be Qt 5.
Note this application does require the QT_DISABLE_SHADER_DISK_CACHE=1 environment variable (or Nsight gets angry about the binary shader cache that Qt 5 introduces). It also requires that the Nsight option to force repaints() be set in order to drive the render calls (technically, you don’t need this as long as you repeatedly invalidate the window 4 or 5 times when you attempt to capture but that gets old quickly). Lastly, passing --coreprofile on the command-line to the sample app.
Hope this helps.
J
UPDATE: I did try updating the driver to 419.35 to see if that would resolve it; it did not. Although this did trigger additional spam about unknown objects being passed to an API at launch which I strangely had to suppress on the D3D options panel which is a bit goofy. I can also seemingly capture one context with this driver and there are API errors showing up all over the scrubber. I will likely not be staying with this version of the driver ;-)
Is anything happening on this front?
Hi J,
Sorry for the delayed response, the team has been in GDC mode for the last two weeks.
Thank you for the repro steps. Our QA team will try to reproduce the issue and get back to you. (DG-4477)
Also, we did a few Qt5 related issues in our 2019.2 release. I don’t want to send you on a fishing expedition, but this very well could fix your issue.
Thanks,
Seth
Thanks for the update, Seth.
I’ll give the new build a go here in the next couple of days.
J
Unfortunately, the new update (2019.2) does not address the internal compiler error in the DSE.
Are there any logs emitted behind the scenes which might yield additional clues as to what the compiler is choking on here?
Would really like to get to the bottom of this as my client’s GL application is Qt5-based and my workflow has become very “impaired” by the absence of the shader editor.
Hey J,
Just wanted to give you an update. We were able to reproduce the issue and are working on it now. I’ll let you know once we fix it.
Currently the fix is slated to be available in our May release, but I might be able to get you something sooner.
Thanks,
Seth
Great news, Seth! Happy to test a patch if you have something available before then.
Hi J,
This has been fixed in a developers local branch and will make it into our next release! (May)
Expect to see it in the 2019.3 release.
Cheers,
Seth
That’s great news, Seth. Glad your team was able to track this down. Any chance of getting a pre-release patch to test locally?
Best,
J
Pleased to report that this issue has been fixed in 2019.3.
Thank you for addressing this and other issues this go around. Looking forward to working with this release.
J
Great to here! Glad it’s working. :)