Hey guys,
first of all, thank you for your software!
the internet is pretty much filled up with Minecraft-guys posting their "Pixel format not accelerated" topics all over all boards, I know, but I have to do this post. I don't play MC, but I'm heavily developing a graphics engine in my freetime (I'm h.pernpeintner from java-gaming.org btw). The project is based on LWJGL 2.9.1 and I never had problems using LWJGL as a dependency. I rewarded myself with a new Notebook recently and now I'm fuled by a GTX 1060 6Gb. With Ubuntu 16 and the latest proprietary drivers from nvidia, everything worked like a charm. Now I switched to Windows 10 and installed the latest drivers. I definetly have the latest drivers installed (378.49, released 24. Jan. 2017) and when I try to run my application, I get a LWJGLException with Pixel format not accelerated. Trying to run the LWJGL 3 examples, I'm getting The driver does not appear to support OpenGL.
I tried to reinstall drivers. I tried to use several older JDK versions. I tried to use 64 and 32 bit java.... running another OpenGL 4 demo works just perfectly fine (no java app). Running World Wind (uses JOGL) just works fine. So I have to assume, that my problem is not driver related.
Is there any chance that we can investigate this problem?
QuoteTrying to run the LWJGL 3 examples, I'm getting The driver does not appear to support OpenGL.
The following is just related to LWJGL 3 and assumes that by the above you meant you tried running an LWJGL 3 example using LWJGL 3 and that failed with this error message.
The first step to narrow it down would be to build and run a native GLFW application, because LWJGL 3 makes use of GLFW to create the window and the OpenGL context. GLFW itself provides a few example programs.
So, you can clone the GLFW GitHub repo (https://github.com/glfw/glfw) and follow its Compiling GLFW (http://www.glfw.org/docs/latest/compile.html) guide.
If you've built GLFW successfully, you'll find some exe files under <builddir>/examples/<buildvariant>/
Try to see if you can run those.
Does your notebook have integrated graphics on the CPU in addition to the GPU? Could it be that your java application uses the integrated graphics chip instead of the regular graphics card?
Thanks you two :)
I try to build glfw, but I think it will work.. all other OpenGL-dependent applications do run.
No, there are no integrated graphics - I have a gsync display (disabled it currently) that doesn't work with integrated graphics, that's why it is deactivated completely.
Quoteall other OpenGL-dependent applications do run.
What _exactly_ are those other (presumably native) OpenGL applications using for window and OpenGL context creation, then?
SDL, GLFW, GLUT, OpenGLUT or Win32 API and WGL manually?
Each such library may have its own way of doing the necessary native Win32 API calls, obtaining the necessary function pointers, catching errors, handling/finding alternatives for unsupported formats, etc.
We first must rule out any error in GLFW itself, because LWJGL 3 itself really does not do anything in addition.
I understand, i will report later about building glfw. So you have any idea what could cause the problem with lwjgl 2, because thats what i am most interested in.
Okay, all glfw examples are working without any problems. Your turn :)
:) okay. Next: can you post a self-contained Java example app that uses LWJGL 3 and provokes the error?
Just to see whether you are not suddenly requesting invalid context or pixel format attributes.
You can also just name a demo application somewhere on GitHub or probably even the lwjgl.org site that does not work.
Btw. can you also try this: https://github.com/httpdigest/lwjgl3-swt/blob/master/test/org/lwjgl/opengl/swt/Swt33CoreMsDemo.java
Just import the project/repo as Maven project into any Java IDE and execute the class. Also supports G-Sync btw.
If that fails, too, then we can at least debug the WGL calls in Java, which are different than the ones done by GLFW at that.
Woa it's getting more and more wierd. I tried the examples from https://github.com/LWJGL/lwjgl3-demos . Running from IntelliJ produces mentioned errors. Running with java -jar xyz.jar results in the same error and the window cannot be created. java -version states java is on the path and is the correct version of my jdk. What puzzles me is, that running it with java.exe -jar xyz.jar from doesn-t-matter-where, it actually works. java -version and java.exe -version point to the exact same java version. Double-clicking a jar works as well somehow. But since I'm using the cmd all the time, I didn't try this earlier...what's also weird is that my compiled project can be started via a batch file that does java -jar -bla.jar but not directly via the cmd with the exact same command.
So first of all, I want to say SORRY, most likely my problem has nothing to do with lwjgl at all. Do you have nonetheless any idea what's going on here?
I have a hunch that it is somewhat related to: https://github.com/LWJGL/lwjgl/issues/119#issuecomment-173983180
Though it so far only seems to affect Intel cards/drivers. Are you absolutely 100% sure that Optimus is not using your Intel HD chip? Please check with GL11.glGetString(GL_VENDOR).
How can one be 100% sure, I'm currently questioning my whole life because the problem is that strange :)
Since I'm not able to create a Display in my own project (in the regular way), how should I query the vendor string?? Using java.exe instead of java for execution, the string says NVIDIA CORPORATION.
I'm relatively sure that there's no Intel stuff kicking in, because it is completely deactivated (in terms of hardware deactivated thingies) in my notebook - since one has to use nvidia cards with gsync.
Do you have any idea why it does matter if I chose java or java.exe?
Okay, now I've upgraded my Nvidia drivers (from 376.62 to 378.49), too, and I have the exact same symptoms now on Windows 7 x64 with JDK1.8.0_121 x64. WTF...
It indeed works when launching on the cmd with java.exe but fails when using java. It also works when using javaw.exe but fails when using javaw. I've definitely not seen this before.
As for why mentioning the '.exe' extension works: I have no idea what Nvidia did there. The fact is that a program can query the command it was started with, and I assume that the Nvidia driver does just that (this is also likely used to detect games for which Nvidia adds certain performance optimizations in their driver), and it will see whether you started Java with the '.exe' extension or not. They seem to have added some code path in their latest driver that checks for java/java.exe there.
I've just verified that indeed it has nothing to do with the Java version and neither with LWJGL. It's really only the command you use to start the process/program.
To test this, I renamed the java.exe in the Java installation directory just to java2.exe.
Starting `java2 -jar the.jar` on the cmd worked. So the Nvidia driver is definitely querying the process's command to do its thing.
As another test, I just renamed any of the built GLFW example exe files to java.exe and ran them in the current working directory as `java`. This resulted in the same error. Again, running with `java.exe` did work and ran that respective GLFW example.
I get that renaming any working native OpenGL application to "java.exe" and starting them inside that working directory as `java` will make them not working anymore.
EDIT: They really screwed up with this one. Even Direct3D 9 and 11 applications do not work anymore if being renamed to "java.exe" and started as "java". :(
I can reproduce this too.
So, since it's not possible to workaround the problem when using IDEs (because they always start "java" to launch your app), I'm now downgrading to an older driver. Very funny that this was the first thing I tried, but I tried it with the 10th latest driver version - which I wasn't able to install and then I gave up early. A very weird optimization Nvidia did there.
I haven't been able to verify this yet, but apparently running java on Windows using this:
CreateProcess( TEXT("..\\jre\\bin\\java.exe"), ...
Also produces the same error, despite running java.exe.
This post on reddit seems to indicate that running javaw.exe rather than java.exe is the solution, but that doesn't mesh with you guys being able to get around it by running java.exe. Again, haven't confirmed - hesitant to update drivers at the moment.
Quote from: avm1979 on January 28, 2017, 16:42:20
apparently running java on Windows using this:
CreateProcess( TEXT("..\\jre\\bin\\java.exe"), ...
Also produces the same error, despite running java.exe.
I cannot reproduce this behaviour. For me, using this program:
#include <stdio.h>
#include <Windows.h>
int main(int argc, char** argv) {
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
ZeroMemory(&pi, sizeof(pi));
if (!CreateProcess(TEXT("any\\relative\\or\\absolute\\path\\to\\java.exe"),
TEXT("any\\relative\\or\\absolute\\path\\to\\java.exe -jar the.jar"), NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
fprintf(stderr, "%s\n", "ERROR!");
fflush(stderr);
return 1;
}
WaitForSingleObject(pi.hProcess, INFINITE);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
return 0;
}
runs just fine. Of course, leaving out the ".exe" extension will not work since CreateProcess() is no shell/command interpreter like cmd.
Also take note that the program name must be repeated in the second argument to CreateProcess() because of conventions on how to call C programs, as mentioned in the documentation of CreateProcess (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx), or otherwise the Java launcher will not see the first command line argument.
EDIT: Changing the "java.exe" to "java" in the _second_ argument of the CreateProcess() call results in the known error. That's probably what you were using/experiencing.
EDIT2: It seems that the Nvidia driver does not like when the first command line argument of the process (argv[0] in C-speak) does not exactly match the last path-segment of the exe module name including the '.exe' file extension the process was started with. Practically with any other application it is possible to specify argv[0] as anything you'd like, such as with this call:
CreateProcess(TEXT("path\\to\\java.exe"), TEXT("whatever -jar the.jar"), ...
This works with any non-OpenGL, non-Direct3D Java application, because the JVM does not care what argv[0] was.
But when running a program that uses OpenGL/Direct3D API via Nvidia's driver, it is a bit different:
Here, it _only_ seems to work when the last path-segment of the module name (the first argument to CreateProcess()) _exactly_ matches the last path-segment of the first command-line argument (the second argument to CreateProcess()). This means, the Nvidia driver checks the executable module name (the exe file) and matches this with the last path-segment of argv[0] of the current process.
It does not seem to matter that the path to the exe module name matches (or even would resolve to a valid/existing file), because this in turn works fine:
CreateProcess(TEXT("path\\to\\java.exe"), TEXT("some\\none\\existing\\path\\to\\java.exe -jar the.jar"), ...
Ah, yeah, that looks like what was happening. In my case, the 2nd parameter did not include the executable name but rather started with -server to run the JVM in server mode. Which I could've sworn it did, but double-checking now, it didn't. Thank you for clearing this up! And pointing me to another bug in the process.
Quote from: avm1979 on January 29, 2017, 06:40:25
Ah, yeah, that looks like what was happening. In my case, the 2nd parameter did not include the executable name but rather started with -server to run the JVM in server mode. Which I could've sworn it did, but double-checking now, it didn't. Thank you for clearing this up! And pointing me to another bug in the process.
Well, according to MSDN you don't need to include the executable name in the 2nd parameter if you already did in the first. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
QuoteIf both lpApplicationName and lpCommandLine are non-NULL, the null-terminated string pointed to by lpApplicationName specifies the module to execute, and the null-terminated string pointed to by lpCommandLine specifies the command line.
As usual, this Win32 API is confusing as hell and full of "if this, then that... -- oh and btw, on Windows X it's different" rules.
Quote from: CoDi on January 30, 2017, 10:31:17
Well, according to MSDN you don't need to include the executable name in the 2nd parameter if you already did in the first. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
Yes, you don't need it for CreateProcess() to know which executable it should run. But you need it because of the C convention that the program name is always the first parameter of the command line (accessible via argv[0] or via the Win32 call GetCommandLine()) because those C programs expect the program name to be in argv[0] and therefore will only parse real command line arguments starting with argv[1].
See:
QuoteConsole processes written in C can use the argc and argv arguments to parse the command line. Because argv[0] is the module name, C programmers generally repeat the module name as the first token in the command line.
I have encountered an issue which I think probably has the same cause. This commit here which worked last week (https://github.com/BenMcLean/libgdx-dos-skin/tree/1aaedecf1d476a8d649b59cacfc735d7aaf70cf0) quit working after the driver upgrade, and now says "Process finished with exit code -1073740791 (0xC0000409)" when launching on desktop. (libGDX 1.9.4's LWJGL backend)
The graphics hardware in my laptop is nVidia GeForce 840M and I managed to fix it for now by downgrading from driver version 378.49 (which I think caused the issue) to version 376.33.
I posted about this on the official nvidia geforce forums (https://forums.geforce.com/default/topic/991055/geforce-drivers/geforce-840m-driver-378-49-breaks-many-java-apps/post/5072632/#5072632) and I expect nVidia would appreciate anyone providing additional info there.
I doubt they will disclose how they messed up, but at least they seem to work on a fix.
I must confess I had a chuckle at this (https://forums.geforce.com/default/topic/989723/geforce-drivers/official-378-49-game-ready-whql-display-driver-feedback-thread-released-1-24-16-/post/5071723/#5071723). I'm a bad person.
QuoteI went back to the previous driver release, after discovering that 378.49 "broke" one of my java reliant Irish Revenue service taxation programs.