On 03/05/2014 05:49 AM, Ákos Tóth wrote:Okay, that's more than a little weird. Optimus seems to mean that we're not getting core functions in the GL dll under Linux... the weird thing is that such a condition *should* just raise an Exception on access, it shouldn't cause a crash. There's nothing accelerate related at that point, so it makes sense that the behaviour is the same with and without it. The particular entry point it's looking up is likely the first one we're seeing which is core, but not supported on the Optimus driver. There were modifications made in the 3.1 loader that means it will attempt to resolve *all* core entry points by DLL lookup, where 3.0.2 was doing a glGet() for the core entry points over 1.1 to see if we had that VERSION supported in a particular context.
The problem appears to have the same symptoms with 2.7 + PyOpenGL 3.1.0b1 - works without Optimus, crashes with Optimus.
I also ran the trace (Optimus, Python 2.7, PyOpenGL 3.1.0b1, file with single line "from OpenGL.GL import *"), the last couple of screens of which is:
Let me know if you need more context than that.
So it seems we need to revisit how to resolve the entry points without blowing up on Optimus yet also without requiring a glGet() during import. It seems likely we need to go back to the lazy-resolution code that waits until the last possible moment to determine whether the entry point is there (i.e. first call or __bool__ check) and only then does the resolution under a GL context.