Software renderer in JOGL? Can support VBO?

Hi,

I recently enabled Github CI to test Jzy3D (which uses JOGL). I have been surprised to see this kind of messages

Unable to create basic Accelerated OpenGL renderer.
Error:  Core Image is now using the software OpenGL renderer. This will be slow.
Error:  WARNING: GL pipe is running in software mode (Renderer ID=0x1020400)

Is this software renderer part of JOGL?

I also wonder if that may be a reason for all my VBO-related test hanging-then-failing with such message

java.lang.RuntimeException: Waited 5000ms for: <bda557d, 51daa76>[count 2 [ add. 0, orig 2], qsz 7, owner <pool-2-thread-2>, add.owner ] - <pool-2-thread-4>

Maybe there is something we can do on our side to fix that:
https://forums.macrumors.com/threads/core-image-is-now-using-the-software-opengl-renderer-this-will-be-slow.2109425/?post=25931190#post-25931190

By the way, it might occur when using a virtual machine. If it occurs only in this case, it won't be worth investigating.

This a mac os delivered by Github CI, so yes, it is most probably a virtual machine.

Sorry for this discussion I thought this was a JOGL message and did not googled before asking.

By the way, it doesn't prevent you from building, does it?

Thanks for caring.

It prevents from testing reliably. I have tests involving VBOs that sometime hang above the max 5000ms accepted by Jogl, sometime do not. Running the same build & test twice may pass or fail so it is a bit exhausting.

The problem is that the bug or limitation might lie in Github continuous integration.

Right. Do you know if this 5000ms limit can be configured? I tried finding in the source tree "Waited" but could not find it :)

Set jogamp.common.utils.locks.Lock.timeout.

Thank you. Seams to work. Configured via Maven.

Good job :) By the way, sorry for the silly question, have you ever used Github continuous integration to build JOGL? It would be nice to be able to do it with Gitlab (because I left Github about one year after Microsoft bought it).

Not yet. But I am indeed working on multiplatform tests for Jzy3D and the capabilities of Github CI are really interesting. Testing a matrix of multiple JDK on multiple OS version of multiple vendors is simple (see my work in progress here)

The problem with Cloud CI in general (github, gitlab or whatever) is that we get VM with low specs and little control on OpenGL versions. For example see my answer about Github Microsoft VM.

It remains possible to setup your own physical CI nodes, but I haven't done this yet.

I'm however interested in going further and try building (and mainly testing) JOGL that way, but I did not built JOGL myself up to now. I can try soon.

Adding self-hosted physical node to Github CI is soooo easy! I just tried with a MacOS and I can get rid of this software renderer issue due to the VM provided by Github. This encourage to go toward multiple physical computers all pointing toward a Cloud CI (whatever the CI is).

I spent so many hours building, improving and maintaining a Jenkins CI with multiple slaves to know that making it work in half a day is an impressive performance (not mine, the tool perf :). I wonder if Jogamp CI is still working? Is it able to test and release everything upon a new commit?



 

Julien, I will start building JOGL 2.4 for M1. I remember that you made some modification in last RC to make it compile properly. May ask you a pointer to your commit so that I continue with your work? Thanks

Are you sure I did it? Sweethome 3D's creator did something to achieve that.

https://forum.jogamp.org/JOGL-for-Mac-ARM-Silicon-tp4040887p4040889.html

Hi,

I was referring to the attempt you have made to build for JDK 17 mentioned here. Did you commit your editions? I tried looking for RC 2.4 on the official git repo but could not find it here.

And yes, I will try applying recipes shared by Manu about building for M1.

If you use --add-opens like me, it should work without modifying the source code. I was waiting for Sven's approval before committing a change on AppContext. Please be aware that you may have to add some other --add-opens clauses when building under other operating systems than GNU Linux.