Hi all – updating this old thread to report that it looks like we’ve finally got the definitive fix for the “Creating the window with GLFW failed!” issue in NVIDIA Texture Tools Exporter 2023.2.0, released on 2023-03-28. If you’re currently experiencing this issue, updating to the newest version should fix it (if it doesn’t, let me know). We also noticed that if you have this issue with the Photoshop plugin, the standalone version will often work (for reasons described below).
Thank you to @igorfak91 for helping me pinpoint the source of this issue and testing different solutions over the previous few months!
I’ll post some technical information here about how we fixed this, in case it helps any other plugin developers searching for this issue.
This issue appeared to occur on some laptops with an Intel® UHD Graphics 630 GPU; our model system was a Lenovo Ideapad C340 with an Intel® Core i5-10210U running at 1920 x 1080 with Lenovo’s v1.05 BIOS. (There may be other factors involved; I could not reproduce this on a Lenovo® Ideapad C340-14IML running at 1366x768 with a v1.07 BIOS.)
On the application side, there’s three phenomena that characterize this issue:
-
glfwCreateWindow()
returns nullptr
;
- The GLFW error message callback returns error 65542, “WGL: The driver does not appear to support OpenGL.”; and
- The above only occurs when the plugin is called from Photoshop; the same code in the standalone
nvtt_export.exe
executable did not produce this issue.
There’s at least one other place this issue has occurred, in Minecraft: for that issue, Intel® released a graphics driver fix: https://www.intel.com/content/www/us/en/support/articles/000058790/graphics.html
In our case, it turned out that the OpenGL driver reported an OpenGL version of 4.6 when running nvtt_export.exe, but an OpenGL version of only 2.1 when running the Exporter Photoshop plugin. Because we used GLFW_CONTEXT_VERSION_MAJOR
and GLFW_CONTEXT_VERSION_MINOR
to request a minimum OpenGL version of 4.5, GLFW window creation failed.
Now, requesting OpenGL 2.1 or 1.0 doesn’t work, as then it appears the driver only provides features available in those versions (and we rely upon some newer OpenGL extensions). So, the first part of the fix was to
- Remove
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, ...)
and glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, ...)
entirely.
- After creating the window and initializing GLEW, check for the presence of each of the OpenGL 3.0+ functions used by the program.
However, this wasn’t a complete fix: we still relied on glGetTextureLevelParameteriv()
, which was added in OpenGL 4.5; the driver provided all the functions we needed except for this one. Luckily, since we were only using it to track the width and height of uploaded textures, we could remove it and replace it by manually tracking texture dimensions.
Finally, we improved the error messages that appear here in the event this occurs on another machine:
- If GLFW window creation fails (implying that no OpenGL is available at all, e.g. we may be on a headless system), we now also suggest using
nvtt_export
’s command-line mode as a workaround, which doesn’t create an OpenGL instance.
- If GLFW window creation succeeded but we couldn’t find the OpenGL functions we needed:
- It lists the first function it couldn’t find.
- We list the most common causes (out-of-date driver, app-specific function limitations, very old GPUs)
- We now print the OpenGL version string as additional diagnostic information
- We note that Windows Sandbox requires additional configuration to enable rendering with an OpenGL version greater than 1.1: Support OpenGL for package validation. · Issue #12906 · microsoft/winget-pkgs · GitHub
Thanks!