Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Cyrille R. <cyr...@gm...>]

> I have tested my program on MacOSX 10.7.5 with NVIDIA GeForce 9400M with
> PyOpenGL 3.0.2a5. It runs fine there. On a third machine running Windows
> 7 with 32 bit python, PyOpenGL 3.0.2b2 and "Intel HD Graphics" (don't
> know which one) the program runs but doesn't display what it's supposed
> to display (which may be a bug in my program).
>
> My guess is that the problem is either restricted to 64 bit python on
> Windows or to 64 bit python with my specific Intel graphics drivers. Are
> there other configurations with 64 bit python on Windows 7 on which
> glGenFramebuffers is reported to work?
>

Yes: I have a Windows 8 64 bits OS with AMD Radeon HD 7870, Python 64 bits,
PyOpenGL 3.0.2 and glGenFramebuffers works fine. More precisely, my
visualization library Galry works on multiple different configurations,
including this Python 64 bits config, except a laptop with the Python 64
bits and Intel HD 3000 card (but works with 32 bits). You can find a
selection of computers where the library works here:
https://github.com/rossant/galry/wiki/Benchmarks


> If it's a problem with the Intel drivers it should also occure when I
> use the native C interface of OpenGL shouldn't it? So if I write a litte
> C test program and compile it once in 32 bit mode and once in 64 bit
> mode I could see if it works, couldn't I? I would be surprised if it
> didn't though since some game developer would have stumbled upon this
> driver bug already, I guess. What do you think?
>

I'd be very interested in seeing the results if you're willing to make the
experiment! My bet is that it will work fine though, and I guess the
problem comes from an interaction between the Python OpenGL bindings and
the drivers.

In fact I think to remember that, when I was investigating this issue, it
was as if the Python bindings were incorrect, in that PyOpenGL tried to
link to the *native* Windows OpenGL 1.1 drivers functions and not the
graphics card drivers ones. So any call to an OpenGL function available in,
say, OpenGL 2.1 and not OpenGL 1.1 would result in a crash.
glGenFramebuffers is such an example, but there were a lot of similar other
OpenGL commands which yielded the same issue. You could try to look for
such commands not available in OpenGL 1.1 and see if this observation is
correct.

I'm writing a scientific program for point cloud processing. While at
> the moment my datasets as well as the memory required for the algorithms
> fit into 4 GB of RAM this may change within the near future (my machine
> has 8 GB). So 32 bit python is only a temporary solution for me. At the
> moment most of my algorithms are CPU based, therefore the graphics
> hardware is mainly needed for display purposes. Therefor the moderately
> fast onboard Intel chip is suficient at the moment. On the other hand it
> even has support for OpenCL which makes it usefull for OpenCL algorithm
> development.


You may be interested in Galry <http://rossant.github.com/galry/>, it is
specifically adapted to OpenGL-based scientific visualization. Let me know
if you make some progress in fixing this bug, as I'd be interested in
including any fix in the library!

Cheers,
Cyrille