Re: [PyOpenGL-Users] Python 3 crash when running on optimus card

[Ákos T. <dxm...@gm...>]

The Optimus driver is basically a secondary X server with the Nvidia
proprietary drivers loaded instead of Mesa (which houses anything the
integrated Intel card is capable of running), so I assume the issue might
be present when running with the Nvidia drivers regardless of Optimus.
Later this week I could do a test where I disable bumblebee altogether and
enable Nvidia on the primary X, thus getting around the whole Optimus deal,
and see if it still happens.


On 5 March 2014 17:11, Mike C. Fletcher <mcf...@vr...> wrote:

> On 03/05/2014 05:49 AM, Ákos Tóth wrote:
>
>> 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:
>> http://pastebin.com/6gicFwsn
>> Let me know if you need more context than that.
>>
>
> 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.
>
> 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.
>
>
> Thanks,
> Mike
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>