Hello everyone, this is a follow-up email because while the bug was closed and OpenMW compiles (and runs) on armhf, what is rendered to the screen via OSG-3.4 is everything but pretty. The short term solution is to disable building OpenMW on armhf and rebuild any builds still online.
I have more below inline... On Thu, Sep 29, 2016 at 11:36 PM, Alberto Luaces <alua...@udc.es> wrote: > > This is a list of facts that I know: > > - OSG "as is" does FTBFS on arm platforms. You can verify that reading > the logs for 3.4: armhf (configured for GLES2) succeeds while armel > (default configuration) breaks. > That is a pity about armel, unfortunately OSG-3.4 with only GLESv2 is useless to OpenMW, regardless of architecture. To my knowledge, OpenMW is the only application linking against OSG-3.4 at the moment. > - The decision of using GLES2 was already made by the Ubuntu team from > whom I took the patches that I told you I was going to apply > beforehand. I suppose they choose GLES2 because nowadays it is rare > to find new hardware supporting GLES1 but not GLES2, but this is mere > speculation. I do not know the reason, but I find any reason to not use standard GL dubious regardless of architecture, specifically when it comes to running Debian and/or Ubuntu on any platform. Not all arm[el|hf] have the same support but GL is the baseline while GLESv[1|2] are just subsets. Normally you would want a derivative Debian or Ubuntu to fork to a specific target GL version. I think it best to try to resolve the issue so that normal GL and not ES[1|2] is used for OSG-3.4 on all platforms since Debian is trying to be consistent across all platforms and architectures. > - On Debian and for 3.4, which depends on Qt5, the decision of using > GLES2 is also taken already for us. See their dependencies on armhf > and armel: > > https://sources.debian.net/src/qtbase-opensource-src/5.6.1%2Bdfsg-3/debian/control/#L309 > This is just plan wrong, as I stated above we should be providing a standard across the board. Qt5 should be using GL on armel/armhf. If this can't be the case, then as a workaround, we should disable building the osgQt plugin. This would allow us to build OSG-3.4 on armhf and armel with GL instead of GLESv2. > I do not know what would happen if we build OSG with GLES1 but linking > to GLES2-enabled Qt5. Does it have any chances of not breaking at > run-time? I am not sure. I tried working around this with OpenMW by disabling building armhf version of openmw-cs that makes use of osgQt. The problem is that GLESv2 render used by OSG-3.4 cannot render OpenMW very well. It doesn't crash which is surprising, and it renders stuff... just nothing anyone would want to play. :) > To me this looks like a packaging problem, because we have to decide > what dependencies we need from a global point of view, instead of in > a case-by-case basis. > It does indeed. I've tested compiling OSG-3.4 without osgQt without the armhf patches (no GLES or EGL) and it compiled just fine. I installed them on my RPi2 and then compiled OpenMW against it. It too compiled without my little work-around patch. The best part is that OpenMW runs, as expected in 1080p glory at 15fps! :) > In my opinion, that tiny patch for OpenMW on Debian looks like a good > compromise. Sadly, I tested this and while it does compile and run, it just render anything useful nor enjoyable. > Regards, > > Alberto Thanks for your comments, we really appreciate your work! :) I hope we can work through this! My recommendation is if we can't get Qt-[4|5] to commit to using GL across all platforms, that OSG-3.4 should disable building the osgQt plugin. Cheers, Bret
