Hi,
I am developing an application in which I use method: void glTransformFeedbackVaryings(int program, int count, String[] locations, int bufferMode); I am pretty sure there must be a bug in win32 implementation of passing the String[] locations argument to OpenGL. On my machine everything works just fine under Linux (same JOGL code) but also everything is OK under Windows in a similar project implemented in 100% in C++. However when this method is used from JOGL under Win32: ... int shaderProgram = gl.glCreateProgram(); int v = getShaderCode(gl, "sample.vs", GL3.GL_VERTEX_SHADER); gl.glAttachShader(shaderProgram, v); String[] vars = new String[] { "Position" }; gl.glTransformFeedbackVaryings(shaderProgram, 1, vars, GL3.GL_SEPARATE_ATTRIBS); gl.glLinkProgram(shaderProgram); ... The linking of program fails with some random chars in place of given variable name: --------- error: Varying (named ¤) specified but not present in the program object. So it looks like OpenGL is receiving incorrect variable name, pointer gets dereferenced incorrectly, etc. Under Linux the linking passes, and if I change the variable name to some incorrect value, I get e.g. "Position" in place where on Windows is this random "¤" char. I would appreciate any help/fix, as this is crucial to me! Thanks, Matt. |
Hello Matt,
a big help would be if you could provide a junit test for this bug. tests are located here: http://github.com/mbien/jogl/blob/master/src/junit/com/jogamp/test/junit http://jogamp.org/wiki/index.php/How_to_Contribute or bugreport + attachment thanks for tracking this down, best regards, michael On 08/18/2010 01:16 AM, Matt [via jogamp] wrote: Hi, -- http://michael-bien.com/ |
Hi Michael,
thanks for prompt reply. Here is the link for the submitted bug with jUnit test attached: http://jogamp.org/bugzilla/show_bug.cgi?id=407 if you need any more info just let me know. Thanks for any help with this. Best regards, Matt. |
Hi,
I'm trying to look into the cause of the bug myself as it is a blocker on Windows for me, but somehow I cannot build the JOGL on Win7. I'm following the build how to, and after starting main ant task I get the following errors: java.generate: java.build: [echo] - - - compiling all java files - - - [echo] test.base.dir ../src/junit [echo] build_t.gen ../build/test/build/gensrc [javac] Compiling 15 source files to C:\Users\Tachyon\Desktop\jogamp\gluegen\build\test\build\classes [javac] C:\Users\T\Desktop\jogamp\gluegen\src\junit\com\jogamp\gluegen\test\junit\generation\BaseClass.java:35: package com.jogamp.common.nio does not exist [javac] import com.jogamp.common.nio.Buffers; [javac] ^ [javac] C:\Users\T\Desktop\jogamp\gluegen\src\junit\com\jogamp\gluegen\test\junit\generation\BaseClass.java:36: package com.jogamp.common.nio does not exist [javac] import com.jogamp.common.nio.PointerBuffer; [javac] ^ ... ... [javac] Note: C:\Users\T\Desktop\jogamp\gluegen\src\junit\com\jogamp\gluegen\test\junit\generation\BindingJNILibLoader.java uses unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 100 errors BUILD FAILED C:\Users\T\Desktop\jogamp\jogl\make\build.xml:33: The following error occurred while executing this line: C:\Users\T\Desktop\jogamp\jogl\make\build-common.xml:345: The following error occurred while executing this line: C:\Users\T\Desktop\jogamp\gluegen\make\build.xml:700: The following error occurred while executing this line: C:\Users\T\Desktop\jogamp\gluegen\make\build-junit.xml:184: The following error occurred while executing this line: C:\Users\T\Desktop\jogamp\gluegen\make\build-junit.xml:103: Compile failed; see the compiler error output for details. There's probably something stupid I'm missing... |
-michael On 08/20/2010 12:49 AM, Matt [via jogamp] wrote: Hi, -- http://michael-bien.com/ |
Well, of course. Building gluegen helped. :)
That is rather obvious, but could be mentioned in the how-to for people following it in the middle of the night. ;) Anyways, the generated JNI code for glTransformFeedbackVaryings seems to 'make sense', so figuring out why it misbehaves on Windows won't be that easy... |
Administrator
|
On Saturday, August 21, 2010 00:53:38 Matt [via jogamp] wrote:
> > Well, of course. Building gluegen helped. :) > That is rather obvious, but could be mentioned in the how-to for people > following it in the middle of the night. ;) > > Anyways, the generated JNI code for glTransformFeedbackVaryings seems to > 'make sense', so figuring out why it misbehaves on Windows won't be that > easy... > http://jogamp.org/bugzilla/show_bug.cgi?id=407 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. > ______________________________________ > View message @ http://jogamp.762907.n3.nabble.com/JOGL-win32-binding-bug-for-glTransformFeedbackVaryings-tp1197405p1255002.html > To start a new topic under jogamp, email [hidden email] > To unsubscribe from jogamp, click http://jogamp.762907.n3.nabble.com/template/NodeServlet.jtp?tpl=unsubscribe_by_code&node=762907&code=c2dvdGhlbEBqYXVzb2Z0LmNvbXw3NjI5MDd8NDU1NjU4MjUx > -- health & wealth mailto:[hidden email] ; http://jausoft.com land : +49 (471) 4707742 ; cell: +49 (151) 28145941 Timezone CET: PST+9, EST+6, UTC+1 |
Big thanks for looking into this bug. I applied your solution of not releasing the tmp var's memory, and it does work indeed. ;)
Since this a one-time invocation, I guess I'll stick to the solution for the time being. Just wondering - should this be posted directly to nvidia? Or is just a bit weird but fully 'legal' behavior of their windows driver (well, even weirder since their driver works on linux) ? |
Administrator
|
On Tuesday, August 24, 2010 23:11:45 Matt [via jogamp] wrote:
> > Big thanks for looking into this bug. I applied your solution of not > releasing the tmp var's memory, and it does work indeed. ;) > Since this a one-time invocation, I guess I'll stick to the solution for the > time being. > Just wondering - should this be posted directly to nvidia? Or is just a bit > weird but fully 'legal' behavior of their windows driver (well, even weirder > since their driver works on linux) ? It's a bug for sure, since there are no requirements in the OpenGL specs stating that life of the arguments must surpass the function call until .. (which is not mentioned neither - of course not). If a lifecycle is requested, ie some PBO buffers, memory maps, then it is explicitly stated. If you like - and I would love it - send an email to NVidia with our findings, eg copy paste our little dialog (ie my email) and CC me sgothel at jausoft dot com. Thank you, Sven |
Free forum by Nabble | Edit this page |