Created attachment 150 [details] jUnit4 test of the bug Bug in method: void glTransformFeedbackVaryings(int program, int count, String[] locations, int bufferMode); Method usage in attached jUnit test. GL profile version: 3 core JOGL version: jogl-b158-2010-08-13_11-02-01 Offending behavior: On Windows the method results in shader linking failure. It seems to be incorrectly passing the argument "locations". Expected behavior is that when the specified location name(s) is(are) proper then the linking of shader passes, and when the location(s) is(are) improper then the message in gl info log contains the given name(s). On Windows (32bit) however the gl info log contains random characters in place where the location name is expected. Everything works fine on Linux. Also native C++ code works fine on the same Windows system.
Comment on attachment 150 [details] jUnit4 test of the bug wrong imports present
Created attachment 151 [details] jUnit4 test of the bug (corrected)
1st of all - thx for the test case. I have changed the test case a bit .. and I can reproduce the bug under windows. Linux - AMD/ATI: Vertex shader(s) failed to link, no fragment shader(s) defined. Linux - NVIDIA: Link info --------- error: Varying (named PPPosition) specified but not present in the program object. Windows7 64bit - NVIDIA: Link info --------- error: Varying (named ??osition) specified but not present in the program object. Link info --------- error: Varying (named ^N) specified but not present in the program object. So I assume that the glTransformFeedbackVaryings mapping doesn't work, probably it's about the char type usage, ie unicode etc.
Tested on windows with skipping releasing the temporary memory, which holds the array of strings (array=malloc(); GetUTFChars() / ReleaseUTFChars() / free()). This 'works' .. It seems that the NV driver executes the glTransformFeedbackVaryings() out of order, ie access the string array after returning the call. Since we release the temp memory right away, this will cause the observed issue. Trying with new 258.96_notebook_winvista_win7_64bit_international_whql.exe driver .. same thing.
This can still be experienced, see latest linux-x64-nvidia windows-x64-amd tests: http://jogamp.org/chuck/job/jogl/lastSuccessfulBuild/label=linux-x86_64/testReport/com.jogamp.test.junit.jogl.glsl/TestTransformFeedbackVeryingsBug407NEWT/ http://jogamp.org/chuck/job/jogl/lastSuccessfulBuild/label=windows-x86_64/testReport/com.jogamp.test.junit.jogl.glsl/TestTransformFeedbackVeryingsBug407NEWT/ We may need to investigate this issue in more detail, ie is this really a NV driver bug ?
linux nvidia: ok windows amd: ok windows nvidia (notebook 258.96): failure (ok test) windows nvidia (notebook 260.99): failure (ok test) reduce priority 1 level, since this is a driver bug. Refined the test case a bit f01d00bb62b75a9e0c4d2926be7e02449a271de6 6f396500e7f595584c2048cebd553b863c90b3c5
The current unit test don't show any more failures. This must have been 'solved' in the NV drivers, I guess. NV/Linux: https://jogamp.org/chuck/view/fwd/job/jogl/277/label=linux-x86_64/testReport/com.jogamp.opengl.test.junit.jogl.glsl/TestTransformFeedbackVaryingsBug407NEWT/ AMD/Win7: https://jogamp.org/chuck/view/fwd/job/jogl/277/label=windows-x86_64/testReport/com.jogamp.opengl.test.junit.jogl.glsl/ I also tested NV/Win7 manually, works as well.