search

HebiRobotics / hebi-scope-feedback

Issue tracker for the Scope user interface
0 stars 0 forks source link

Special case Software rendering for 16.04 #73

Closed ennerf closed 3 years ago

ennerf commented 5 years ago

Related to #33. We changed the default to use hardware acceleration, but there are still plenty of users who use 16.04 and are running into the memory leak issue.

It's ok to keep the default to be accelerated, but at least 16.04 should be special cased to software mode.

rLinks234 commented 5 years ago

If you get the OpenGL profile version string, it will tell you which version of Mesa they are using. For example, my Fedora 29 machine returns 4.5 (Core Profile) Mesa 18.3.6

I'm looking for the freedesktop bug report related to this issue and will let you know which specific version was fixed. Any version after said issue was fixed shouldn't have any issues with hw acceleration enabled by default

rLinks234 commented 5 years ago

If I were to guess which issue we're talking about here, it would be related to this JFX issue (there are probably some duplicates, but this has the most relevant info):

https://bugs.openjdk.java.net/browse/JDK-8161997

As the reporter mentioned, the problem is within the native method Java_com_sun_prism_es2_X11GLContext_nMakeCurrent. This corresponds to making the GLX (X11 GL context) current. This corresponds to the memory leak reported at freedesktop in MakeContextCurrent within the glxcurrent.c file in the MESA stack:

https://bugs.freedesktop.org/show_bug.cgi?id=100741

It seems that this was fixed in MESA 17.2.0

Also seeing the specific commit mentioned in the freedesktop bug tracker (fd6c2a3f3eb7f5f3077fb95b1441ddaa43b806fe) and viewing which tags are derived from it makes me think any version >= 17.2.0 won't need the sw renderer as a workaround for this

ennerf commented 5 years ago

Thanks! Do you also happen to know how I can read the OpenGL profile version String?

rLinks234 commented 5 years ago

The standard way would be to create an OpenGL context (GLX context) and query the renderer string. The quickest and most "light-weight" solution would be to create an offscreen OpenGL context through GLX and parse the string from glGetString(GL_VERSION), while being careful to ignore any cases that aren't Mesa (there are some GL drivers not using Mesa - e.g., NVIDIA proprietary drivers).

The glGetString(GL_VERSION) is basically what glxinfo does, but sadly, we can't rely on that program being installed on all GNU/Linux machines.

So for instance, my computer returns the string 4.5 (Core Profile) Mesa 18.3.6 for glGetString(GL_VERSION).

I think it would be sufficient enough to just continue the special "software rendering" logic based on if Mesa is in the string, and then try and parse a version number after that. Technically, this is only an issue for Intel (i915) specific devices, so realistically we should do a glGetString(GL_VENDOR) and check for Intel in the string...

I'll keep looking to see if there is an easier way to do this, since I know this sounds very painful :)

ennerf commented 5 years ago

Snapshot uses OpenJFX 13, which may have gotten rid of this issue