Created attachment 768 [details] Output of test.bat After upgrade from Win7 to Windows 10, JOGL now receives a GL2 software profile when it was previously (prior to upgrade) received a Gl2 hardware profile from these same drivers. Also the version number given out is 1.1 on this software profile so some applications will not run. Attached is the output of a test.bat run with no parameters changed. Environment: Jogamp 2.3.2 Java 1.8.0_66 (64bit) Dell XPS13 laptop Windows 10 Intel HD Graphics 3000 card. The drivers are the latest available from here https://downloadcenter.intel.com/product/81500/Intel-HD-Graphics-3000-for-2nd-Generation-Intel-Core-Processors Notes: I've just reinstalled the drivers before running the test. This was working well before the change to Windows 10, the OS is the only change I can see. The Intel Drivers are pre-Windows 10 release date, but presumably written with it in mind. On various forums other users mention trouble with Windows 10 and these cards, but nothing related to 3D (that I can find easily). There are several similar sounding mapping bugs, so it may be related e.g. https://jogamp.org/bugzilla/show_bug.cgi?id=1084
Please can you provide a tiny test case to reproduce your bug? How do you get a GL profile?
(In reply to Julien Gouesse from comment #1) > Please can you provide a tiny test case to reproduce your bug? How do you > get a GL profile? I did the simplest thing I could do. I got the latest jogamp-all-platforms.7z http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z I extracted it to my temp folder I double click the test.bat file that is in the root, without any arguments or changes at all Though I hardly need to state it, that file runs this command: set BLD_DIR=jar set CP_ALL=.;%BLD_DIR%\gluegen-rt.jar;%BLD_DIR%\jogl-all.jar echo CP_ALL %CP_ALL% set X_ARGS="-Dsun.java2d.noddraw=true" "-Dsun.awt.noerasebackground=true" REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.opengl.awt.GLCanvas > java-win64.log 2>&1 REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.common.GlueGenVersion > test.log 2>&1 REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.nativewindow.NativeWindowVersion >> test.log 2>&1 REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.opengl.JoglVersion >> test.log 2>&1 REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.newt.NewtVersion >> test.log 2>&1 REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.newt.opengl.GLCanvas >> test.log 2>&1 java -classpath %CP_ALL% %X_ARGS% com.jogamp.newt.opengl.GLWindow >> test.log 2>&1 type test.log And then I attached the test.log file to this bug report, along with machine info. As you can see that log file doesn't contain ".hw" at all. The bat file really only runs the GLWindow main method. If I start putting together code of my own I fear I'll make it more complex not simpler.
(In reply to Phil Jordan from comment #2) > (In reply to Julien Gouesse from comment #1) > > Please can you provide a tiny test case to reproduce your bug? How do you > > get a GL profile? > > I did the simplest thing I could do. I got the latest jogamp-all-platforms.7z > http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z > > I extracted it to my temp folder > I double click the test.bat file that is in the root, without any arguments > or changes at all > > Though I hardly need to state it, that file runs this command: > > set BLD_DIR=jar > > set CP_ALL=.;%BLD_DIR%\gluegen-rt.jar;%BLD_DIR%\jogl-all.jar > echo CP_ALL %CP_ALL% > > set X_ARGS="-Dsun.java2d.noddraw=true" "-Dsun.awt.noerasebackground=true" > > REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.opengl.awt.GLCanvas > > java-win64.log 2>&1 > > REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.common.GlueGenVersion > > test.log 2>&1 > REM java -classpath %CP_ALL% %X_ARGS% > com.jogamp.nativewindow.NativeWindowVersion >> test.log 2>&1 > REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.opengl.JoglVersion >> > test.log 2>&1 > REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.newt.NewtVersion >> > test.log 2>&1 > REM java -classpath %CP_ALL% %X_ARGS% com.jogamp.newt.opengl.GLCanvas >> > test.log 2>&1 > java -classpath %CP_ALL% %X_ARGS% com.jogamp.newt.opengl.GLWindow >> > test.log 2>&1 > > type test.log > > And then I attached the test.log file to this bug report, along with machine > info. As you can see that log file doesn't contain ".hw" at all. > The bat file really only runs the GLWindow main method. > > If I start putting together code of my own I fear I'll make it more complex > not simpler. Thanks. Do you call GLProfile.getMaxFixedFunc(true)? (true = favorHardwareRasterizer)
public void main(String[] args) of com.jogamp.newt.opengl.GLWindow with no arguements calls glp = GLProfile.getDefault(); final GLCapabilitiesImmutable caps = new GLCapabilities( glp ); System.err.println("Requesting: "+caps); final GLWindow glWindow = GLWindow.create(caps); glWindow.setSize(128, 128); so the answer is no I the code I invoke doesn't call GLProfile.getMaxFixedFunc(true), I'll try building a modified jar with Max in it and test it out on that machine.
As far as I know, the Dell XPS 13 has a Intel HD Graphics 4400, not a Intel HD Graphics 3000. Please call GLProfile.getMaxFixedFunc(true) and caps.setDepthBits(24).
The wrong windows graphics device is picked when not using VersionApplet: http://forum.jogamp.org/Bad-GL-RENDERER-detection-tp4036346.html WindowsGraphicsDevice[type .windows, connection decon] WindowsGraphicsDevice[type .windows, connection decon, unitID 0, handle 0x0, owner false, NullToolkitLock[obj 0x511baa65]]
The default device returned by the drawable factory is probably not the same in the both situations: https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/GLProfile.java#L1777
Phil, please test this workaround, call GLProfile.getDefault(new WindowsGraphicsDevice(0)), it would work like in VersionApplet.
Actually, there is no difference in the graphics device, VersionApplet just shows less information about it: https://github.com/sgothel/jogl/blob/master/src/jogl/classes/jogamp/opengl/awt/VersionApplet.java#L165 https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/JoglVersion.java#L147
Just a quick update, I get the same behavior as described here: http://forum.jogamp.org/Bad-GL-RENDERER-detection-td4036346.html When I run the test.bat or Java3D on my Intel laptop, jogl can't see any hardware drivers, but if I run the JNLP http://jogamp.org/deployment/jogamp-current/jogl-application-version.jnlp The console shows the various dlls being loaded and returns a hardware renderer profile. I notice the list of dlls loaded by the jp2launcher.exe (jnlp?) look nothing like what's loaded in the javaw.exe (see below) Running the VersionApplet from eclipse as an applet, return software only, but also appears to be started in javaw.exe dlls loaded from javaw.exe [0] "C:\\Program Files\\Java\\jdk1.8.0_92\\jre\\bin\\zip.dll" (id=62) [1] "C:\\Program Files\\Java\\jdk1.8.0_92\\jre\\bin\\awt.dll" (id=64) [2] "C:\\Program Files\\Java\\jdk1.8.0_92\\jre\\bin\\fontmanager.dll" (id=65) [3] "C:\\Program Files\\Java\\jdk1.8.0_92\\jre\\bin\\net.dll" (id=66) [4] "C:\\Program Files\\Java\\jdk1.8.0_92\\jre\\bin\\nio.dll" (id=67) [5] "C:\\Users\\Soiz\\AppData\\Local\\Temp\\jogamp_0000\\file_cache\\jln566946243995713151\\jln9136045050779793023\\natives\\windows-amd64\\gluegen-rt.dll" (id=68) [6] "C:\\Program Files\\Java\\jdk1.8.0_92\\jre\\bin\\jawt.dll" (id=69) [7] "C:\\Users\\Soiz\\AppData\\Local\\Temp\\jogamp_0000\\file_cache\\jln566946243995713151\\jln9136045050779793023\\natives\\windows-amd64\\nativewindow_awt.dll" (id=70) [8] "C:\\Users\\Soiz\\AppData\\Local\\Temp\\jogamp_0000\\file_cache\\jln566946243995713151\\jln9136045050779793023\\natives\\windows-amd64\\nativewindow_win32.dll" (id=71) [9] "C:\\Users\\Soiz\\AppData\\Local\\Temp\\jogamp_0000\\file_cache\\jln566946243995713151\\jln9136045050779793023\\natives\\windows-amd64\\jogl_desktop.dll" (id=72) [10] "C:\\Users\\Soiz\\AppData\\Local\\Temp\\jogamp_0000\\file_cache\\jln566946243995713151\\jln9136045050779793023\\natives\\windows-amd64\\jogl_mobile.dll" (id=73) dlls loaded (or at least reported by jnlp VersionApplet: init() - begin JNLPClassLoader: Finding library java.dll JNLPClassLoader: Finding library jawt.dll JNLPClassLoader: Finding library jawt.dll JNLPClassLoader: Finding library OpenGL32.dll JNLPClassLoader: Finding library libGLESv3.so.3.dll JNLPClassLoader: Finding library libGLESv3.so.dll JNLPClassLoader: Finding library GLESv3.dll JNLPClassLoader: Finding library GLES30.dll JNLPClassLoader: Finding library libGLESv3.dll JNLPClassLoader: Finding library libGLES30.dll JNLPClassLoader: Finding library libGLESv2.so.2.dll JNLPClassLoader: Finding library libGLESv2.so.dll JNLPClassLoader: Finding library GLESv2.dll JNLPClassLoader: Finding library GLES20.dll JNLPClassLoader: Finding library GLESv2_CM.dll JNLPClassLoader: Finding library libGLESv2.dll JNLPClassLoader: Finding library libGLESv2_CM.dll JNLPClassLoader: Finding library libGLES20.dll JNLPClassLoader: Finding library libEGL.so.1.dll JNLPClassLoader: Finding library libEGL.so.dll JNLPClassLoader: Finding library EGL.dll JNLPClassLoader: Finding library libEGL.dll JNLPClassLoader: Finding library libGLESv1_CM.so.2.dll JNLPClassLoader: Finding library libGLESv1_CM.so.dll JNLPClassLoader: Finding library GLESv1_CM.dll JNLPClassLoader: Finding library GLES_CM.dll JNLPClassLoader: Finding library GLES_CL.dll JNLPClassLoader: Finding library libGLESv1_CM.dll JNLPClassLoader: Finding library libGLES_CM.dll JNLPClassLoader: Finding library libGLES_CL.dll JNLPClassLoader: Finding library libEGL.so.1.dll JNLPClassLoader: Finding library libEGL.so.dll JNLPClassLoader: Finding library EGL.dll JNLPClassLoader: Finding library libEGL.dll JNLPClassLoader: Finding library OpenGL32.dll JNLPClassLoader: Finding library libEGL.so.1.dll JNLPClassLoader: Finding library libEGL.so.dll JNLPClassLoader: Finding library EGL.dll JNLPClassLoader: Finding library libEGL.dll
Sorry my last comment was a bit vague on the loaded dlls here is what tasklist show for each C:\WINDOWS\system32>tasklist /fi "ImageName eq javaw.exe" /m Image Name PID Modules ========================= ======== ============================================ javaw.exe 4004 ntdll.dll, KERNEL32.DLL, KERNELBASE.dll, ADVAPI32.dll, msvcrt.dll, sechost.dll, RPCRT4.dll, USER32.dll, GDI32.dll, COMCTL32.dll, combase.dll, bcryptPrimitives.dll, IMM32.DLL, msvcr100.dll, jvm.dll, PSAPI.DLL, WSOCK32.dll, WS2_32.dll, WINMM.dll, VERSION.dll, WINMMBASE.dll, cfgmgr32.dll, verify.dll, java.dll, zip.dll, SHELL32.dll, windows.storage.dll, shlwapi.dll, kernel.appcore.dll, shcore.dll, powrprof.dll, profapi.dll, awt.dll, OLEAUT32.dll, apphelp.dll, DWMAPI.DLL, uxtheme.dll, MSCTF.dll, ole32.dll, fontmanager.dll, net.dll, mswsock.dll, nio.dll, t2k.dll, clbcatq.dll, CRYPTSP.dll, rsaenh.dll, bcrypt.dll, USERENV.dll, CRYPTBASE.dll, IPHLPAPI.DLL, NSI.dll, dhcpcsvc6.DLL, dhcpcsvc.DLL, gluegen-rt.dll, jawt.dll, nativewindow_awt.dll, nativewindow_win32.dll, OpenGL32.dll, GLU32.dll, DDRAW.dll, DCIMAN32.dll, jogl_desktop.dll, jogl_mobile.dll, RICHED20.DLL, USP10.dll, msls31.dll, dataexchange.dll, d3d11.dll, dcomp.dll, dxgi.dll, twinapi.appcore.dll C:\WINDOWS\system32> C:\WINDOWS\system32>tasklist /fi "ImageName eq jp2launcher.exe" /m Image Name PID Modules ========================= ======== ============================================ jp2launcher.exe 1944 ntdll.dll, KERNEL32.DLL, KERNELBASE.dll, USER32.dll, MSVCR100.dll, GDI32.dll, ole32.dll, combase.dll, msvcrt.dll, RPCRT4.dll, bcryptPrimitives.dll, sechost.dll, OLEAUT32.dll, IMM32.DLL, ADVAPI32.dll, ntmarta.dll, jvm.dll, PSAPI.DLL, WSOCK32.dll, WS2_32.dll, VERSION.dll, WINMM.dll, WINMMBASE.dll, cfgmgr32.dll, verify.dll, java.dll, awt.dll, apphelp.dll, SHELL32.dll, windows.storage.dll, shlwapi.dll, kernel.appcore.dll, shcore.dll, powrprof.dll, profapi.dll, uxtheme.dll, jli.dll, COMCTL32.dll, zip.dll, deploy.dll, imagehlp.dll, urlmon.dll, WININET.dll, iertutil.dll, net.dll, mswsock.dll, nio.dll, MSCTF.dll, dwmapi.dll, fontmanager.dll, t2k.dll, SspiCli.dll, ondemandconnroutehelper.dll, IPHLPAPI.DLL, winhttp.dll, WINNSI.DLL, NSI.dll, DNSAPI.dll, rasadhlp.dll, fwpuclnt.dll, bcrypt.dll, CRYPT32.dll, MSASN1.dll, CRYPTSP.dll, rsaenh.dll, CRYPTBASE.dll, clbcatq.dll, WindowsCodecs.dll, dataexchange.dll, d3d11.dll, dcomp.dll, dxgi.dll, twinapi.appcore.dll, dcpr.dll, management.dll, USERENV.dll, dhcpcsvc6.DLL, dhcpcsvc.DLL, gluegen-rt.dll, jawt.dll, nativewindow_awt.dll, nativewindow_win32.dll, OpenGL32.dll, GLU32.dll, DDRAW.dll, DCIMAN32.dll, jogl_desktop.dll, jogl_mobile.dll, ig4icd64.dll, RICHED20.DLL, USP10.dll, msls31.dll C:\WINDOWS\system32>
I notice that the file ig4icd64.dll appears in the jp2launcher dll list but not the javaw list. I also notice that this file is in the driver details for the intel graphics card, so it looks like the failure to load the intel driver is the problem... but why one and not the other?
As seen else where on the web, this problem exists for Intel grahpics drivers using java later than Java8 u45 For example: https://github.com/LWJGL/lwjgl/issues/119 I've tested on java7 and Java8 u25 and the issue does not exist, that is to say everything works perfectly. I can clearly see teh intel openGL driverr dll in the list of drivers (using cmd: tasklist /fi "ImageName eq javaw.exe" /m ) Given that this problem exists with a totally different set of binding in the exact same circumstances I feel the javaw.exe is the issue, and either down grading to java8 45 or setting up a java webstart jnlp are the only 2 solutions
According to Spasi's comments, the bug is in the driver and his workaround is the only one I can suggest: https://github.com/LWJGL/lwjgl/issues/119#issuecomment-173983180 These drivers are a bit broken and unsupported according to Intel: https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/607695#comment-1858657 The workaround above is better than nothing but it can have nasty effects. We have to find another workaround within JOGL if possible.
Instead of providing no OpenGL driver for Windows 10, Intel provides a driver that fails to load for its discontinued hardware. When a signed software claims to support Windows 10 which is the case of Oracle Java and OpenJDK 1.8.0 update 60 and later, the driver loads to load and Microsoft GDI Generic driver is used instead. I fear that Java Webstart will follow the same route than applets (deprecated in Java 1.9, removed from Java 1.10). I remind that Java Webstart is mostly unusable without paying for a "trusted" certificate or tinkering the JRE. I don't advise to use an old version of Java as it exposes to vulnerabilities. Therefore, there is no acceptable workaround (Java Webstart or downgrading to OpenJDK 1.8.0 update 55). If we lied to the the driver somehow, it would "work" but as it's not maintained, the bugs would remain unfixed. Intel is to blame here, there is nothing that we can do. On the long term, using Mesa or Angle under Windows in these cases might help: https://jogamp.org/bugzilla/show_bug.cgi?id=1179
Using this shim should fix the problem in most of the cases: https://communities.intel.com/servlet/JiveServlet/download/523544-180582/legacy-igpu-x64.zip