We are about to switch to a new forum software. Until then we have removed the registration on this forum.
I'm trying to use Processing (3.3.7 ARMv6hf) on ODROID-XU4 on which Oracle JDK 8u162 32-bit ARM version is installed. The X11 configuration file (/etc/X11/xorg.conf) has been modified with the following lines appended to use OpenGL ES instead of OpenGL.
Section "Module"
Disable "glx"
EndSection
For a simple test, I made the following sketch which is running without any problems of course.
void setup() {
size(300, 300);
}
void draw() {
background(0);
}
However, if I make a change in size(300, 300) like the following,
size(300, 300, P3D);
I get the following error messages.
OpenGL error 1280 at bot beginDraw(): invalid enumerant
java.lang.RuntimeException: GL function glRenderbufferStorageMultisample() is not available on this hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for help.
at processing.opengl.PJOGL.renderbufferStorageMultisample(PJOGL.java:1941)
at processing.opengl.PGL.createFBOLayer(PGL.java:955)
at processing.opengl.PGL.beginRender(PGL.java:727)
at processing.opengl.PGraphicsOpenGL.beginOnscreenDraw(PGraphicsOpenGL.java:6577)
at processing.opengl.PGraphicsOpenGL.beginDraw(PGraphicsOpenGL.java:1459)
at processing.core.PApplet.handleDraw(PApplet.java:2388)
at processing.opengl.PSurfaceJOGL$DrawListener.display(PSurfaceJOGL.java:866)
at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:692)
at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:674)
at jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:443)
at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1293)
at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1147)
at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:759)
at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:81)
at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:452)
at com.jogamp.opengl.util.FPSAnimator$MainTask.run(FPSAnimator.java:178)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Would someone please help me resolve this problem?
Many thanks,
Scott
Answers
Tagging @gohai
Kf
@kfrajer, thanks for pointing the cause of the problem. Does this mean that there's no way I can use P2D or P3D on this platform (ODROID-XU4)?
Hi @seongwook. We might be able to disable multisampling for your ODROID-XU4. Could you run the "Demos/Tests/SpecsTest" example and post the output here? (Specifically interested in the renderer name of your driver.) Thanks!
Hi @gohai,
Sorry for my belated response. Here is the output I got from Demos/Tests/SpecsTest.pde as it is.
Many thanks!
Thank you @seongwook!
Could you try replacing
core.jar
that comes with your copy of Processing with the following file, and see if this makes a difference?http://sukzessiv.net/~gohai/p5-arm/mali/core.jar
Hi @gohai,
As you instructed, I replaced /core/library/core.jar with the file you uploaded.
I ran the modes/java/examples/Demos/Tests/SpecsTest/SpecsTest.pde and I got the following output which looks quite similar to the old output.
However, I got something different for the following original code.
The output is just:
without the error that I used to have :) Is this a right sign for me to go with P3D on ODROID-XU4?
Many thanks,
Scott
@seongwook Thanks for testing! The original code is with
P3D
?@seongwook I have also uploaded a new version of the file for you that could get rid of the RuntimeException. Please test. Thank you!
http://sukzessiv.net/~gohai/p5-arm/mali/core.jar
Hi @gohai,
I'm sorry I mistyped the original code. Yes, the test was with P3D and I got the simple one line output.
I'll do the tests again with the updated core.jar and let you know what I got.
Thanks,
Scott
Hi @gohai,
I just did the tests. Their two output results are identical to what I got previously. That is, nothing seems to differentiate.
Please let me know if there are some other tests I need to run.
Thanks,
Scott
@seongwook Thanks for testing! I uploaded one last attempt for today - please let me know if this makes any difference:
http://sukzessiv.net/~gohai/p5-arm/mali/core.jar
Hi @gohai,
Now I just tested the core.jar you lately updated. However, the results are exactly the same :(
Please let me know if there's another update.
Many thanks,
Scott
Hi @seongwook,
I am a bit confused - can you double-check that you are running the latest file? (I also re-compiled, and re-uploaded it, just to be sure.)
Because at the very least, the new version should have printed "numSamples is: " to the console, see here. Your stacktrace above seems to be calling this
createFBOLayer
function.Hi @gohai,
Hm... it's weird. Please let me check if the core.jar files I downloaded are correct.
Would you please check if these are correct?
Thanks,
Scott
@seongwook
I just re-compiled and uploaded:
http://sukzessiv.net/~gohai/p5-arm/mali/core.jar
MD5 (core.jar) = 081feb5fff944b9a84640234cd79c70f
Can you download this, check the md5sum and paste the output?
Hi @gohai,
I just downloaded core.jar again and found that its MD5 checksum is identical (081feb5fff944b9a84640234cd79c70f).
I ran the test script (i.e., modes/java/examples/Demos/Tests/SpecsTest/SpecsTest.pde) and got the following output:
Please verify this for me.
Thanks,
Scott
@seongwook
Thank you - this clears it up. The stack trace might look similar to you, but this one has the "numSamples" line, and the function that is missing (glReadBuffer) is also different than the one above.
I tried to fix this one now - feel free to test this and send new output when you get to it: http://sukzessiv.net/~gohai/p5-arm/mali/core.jar
Hi @gohai,
Thanks for your thorough investigation :)
I got the last core.jar and tested it. Now, I got the completely different output:
Would please take a look at this for me?
Thanks,
Scott
@seongwook
Thanks! Could you please test the latest file and post the output? (This will not yet fix this one.) Believe we should be close, though..
Hi @gohai,
Actually, the output that I just posted is the result that I got by running modes/java/examples/Demos/Tests/SpecsTest/SpecsTest.pde with core.jar that you lastly uploaded (MD5 checksum = e18fe00179593b1e65c786877b81fb8b). Please let me know if I did a wrong test.
I'm excited about getting closer to fixing it :)
Thanks,
Scott
@seongwook Can you try the latest (md5: a67e98737bffbf0f955f4dd8196de90a), and post the output again?
@gohai, please take a look at the following output I got from testing core.jar (MD5 checksum = a67e98737bffbf0f955f4dd8196de90a).
Thanks,
Scott
@seongwook New file with md5 c8409147464f96885d2e2c52f7038e0f is up.
@gohai, here's the output of the file with MD5 of c8409147464f96885d2e2c52f7038e0f:
@seongwook Uploaded new file with md5 f2024042a659d2beb89979ed3082f965.
@gohai, wow~! I got the following clean output from the new file with MD5 of f2024042a659d2beb89979ed3082f965:
Thank you so much for fixing the problem!
BTW, can I simply ignore the error message in the very first line?
This one seems to have been there at all times.
Thanks,
Scott
@seongwook Thats great to hear. Thanks you for diligently testing and providing me with feedback!
If you still have time, could you test this one, and see if it (still) works: md5 5601a9174287d2b83c6979bd23164a7d. (I initially disabled multisampling for framebuffers, but later found what could have been the root cause, so I'd love to try to turn it on again.)
As for the message in the first line: you can ignore this. (There is a way to find out what caused this, but it is a little bit involved.)
Hi @gohai,
I DO have time to do more tests and I love to see Processing becoming better and better :) So, please let me know anytime if there's something I can test more.
Here's the output from testing core.jar with MD5 of 5601a9174287d2b83c6979bd23164a7d.
Many thanks,
Scott
@seongwook Thank you, this is very generous of you, Scott!
Uploaded a new file, md5 17bbc579d2a2f061273613653d171a58.
@gohai, this is really my big pleasure!
I did the test with MD5 17bbc579d2a2f061273613653d171a58 and I got the following clean output :)
@seongwook If the following also works cleanly, this would be the last for now: 5d4d3a559d7b54fe68aaae4837a9f4d6 :) Please let me know!
@gohai, the last one (MD5: 5d4d3a559d7b54fe68aaae4837a9f4d6) worked as follows :)
I'm so glad that we finally got to the final destination!
Thank you so much for your effort!
@seongwook Arr, did I say the last one? :) If you have time, there's just one more... 8d60f1c34716c3e4fd7fb682c35a984e. I refactored the changes a bit and submitted a pull-request so that this will become part of future official releases of Processing. (The one I just uploaded makes sure I did not make a mistake in the process, it should work as good as the previous version.) Thanks.
@gohai, don't worry! I'll be here for more tests :)
BTW, here's the output of core.jar with MD5 8d60f1c34716c3e4fd7fb682c35a984e which doesn't look like what you expected.
Please let me know if there's another one ready to be tested.
@seongwook How is the latest file, dfdf52cf2915b48ba197dacda92b0c70?
If it works, could you also test the following sketch with it:
@gohai, the file with MD5 dfdf52cf2915b48ba197dacda92b0c70 worked cleanly as follows:
In addition, the output of the simple sketch is this:
which looks quite good :)
@seongwook
Thank you! Does it still work with lights, e.g.
@gohai, it doesn't seem to work unfortunately :( Please take a look at the output.
@seongwook Another try: 2cb68f4062dd97fda9f9c9cb734ef527
If you could see if this makes the lights example work?
@gohai, it seems to work. The output of SpecsTest.pde is as clean as what we had previously. And the console output of the lights example is also clean like the following:
Its screen output is this:
I guess this is what you expected :)
@seongwook Fantastic, thanks so much!
As for the (harmless) OpenGL error: if you wanted you could try to add
-Djogl.debug.DebugGL
to the linerun.options=
in the file~/.processing/preferences.txt
(make sure you close Processing before starting to edit). Afterwards, opening Processing and running a P3D sketch that triggered the error before, should print a stack trace when it happens - which should point to exactly what is causing this. But is has been quite some time since I had did this, so I might be wrong on the exact steps ;)@gohai, as you instructed, I modified ~/.processing/preferences.txt and ran the following simple sketch.
And I got the following console output:
Can you point out what causes the error from this clue?
@seongwook Thank you, that was all the information I needed! I uploaded a108bd998432b7b544ce0e1d0ad73376, which should prevent this message
Hi @gohai,
I'm sorry for my late response. I had a day off yesterday :)
Here's the output of a108bd998432b7b544ce0e1d0ad73376.
@seongwook Interesting. What happens if you're not running with
-Djogl.debug.DebugGL
? Do you still see an error or warning in the console? Do things still work the way the did before? (e.g. at 2cb68f4062dd97fda9f9c9cb734ef527)@gohai, I just carried out a test with the latest core.jar of MD5 a108bd998432b7b544ce0e1d0ad73376 and without
-Djogl.debug.DebugGL
. Its output is just:which is different from what was executed with
-Djogl.debug.DebugGL
.@seongwook Thank you. I uploaded a new file, 81002c7ebdaabfae16db1c9915bdff70
@gohai, I just tested it (MD5 81002c7ebdaabfae16db1c9915bdff70) with and without
-Djogl.debug.DebugGL
. Both ran cleanly without making any console output. That is,OpenGL error 1280 at bot beginDraw(): invalid enumerant
wasn't generated :)Fantastic to hear, @seongwook. Thanks so much for your time and good spirit in testing!
@gohai, thank you so much for having made me do something for Processing :)
If there's something I can do more, please don't hesitate to ask me.
Many thanks,
Scott