Thread: [PyOpenGL-Users] access violation when calling glGenFramebuffers
Brought to you by:
mcfletch
From: Patrick D. <pyo...@pd...> - 2013-04-03 15:46:28
|
Hi everyone, I have a problem when calling glGenFramebuffers on Windows 7 64 bit: Traceback (most recent call last): ... File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 197, in __init__ self.framebuffer_id = glGenFramebuffers(1); File "latebind.pyx", line 32, in OpenGL_accelerate.latebind.LateBind.__call__ (src\latebind.c:667) File "wrapper.pyx", line 308, in OpenGL_accelerate.wrapper.Wrapper.__call__ (s rc\wrapper.c:5356) File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", line 379 , in __call__ return self( *args, **named ) WindowsError: exception: access violation writing 0xFFFFFFFFEA94A760 My PyOpenGL version is 3.0.2, including PyOpenGL_accelerate 3.0.2. I have installed both packages with the windows installers (AMD64 versions). My graphics adaptor is an Intel HD Graphics 4000 for which I'm using the newest drivers (version 9.17.10.2843). Calling bool(glGenFramebuffers) just before the call to glGenFramebuffers returns True. I have also tried to use the extension version glGenFramebuffersEXT but with the same result. What might be the problem and how can I work around it? How can I access the low level C-routines of OpenGL? Cheers, Patrick |
From: Cyrille R. <cyr...@gm...> - 2013-04-03 15:50:22
|
I had a similar problem with a similar configuration and a similar graphics card. I couldn't solve the problem, so I ended up removing my whole 64 bits Python distribution and reinstalling everything with Python 32 bits... and it worked. Cyrille 2013/4/3 Patrick Dietrich <pyo...@pd...> > Hi everyone, > > I have a problem when calling glGenFramebuffers on Windows 7 64 bit: > > Traceback (most recent call last): > ... > File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 197, in > __init__ > self.framebuffer_id = glGenFramebuffers(1); > File "latebind.pyx", line 32, in > OpenGL_accelerate.latebind.LateBind.__call__ > (src\latebind.c:667) > File "wrapper.pyx", line 308, in > OpenGL_accelerate.wrapper.Wrapper.__call__ (s > rc\wrapper.c:5356) > File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", > line 379 > , in __call__ > return self( *args, **named ) > WindowsError: exception: access violation writing 0xFFFFFFFFEA94A760 > > My PyOpenGL version is 3.0.2, including PyOpenGL_accelerate 3.0.2. I > have installed both packages with the windows installers (AMD64 > versions). My graphics adaptor is an Intel HD Graphics 4000 for which > I'm using the newest drivers (version 9.17.10.2843). > > Calling bool(glGenFramebuffers) just before the call to > glGenFramebuffers returns True. I have also tried to use the extension > version glGenFramebuffersEXT but with the same result. > > What might be the problem and how can I work around it? > How can I access the low level C-routines of OpenGL? > > Cheers, > Patrick > > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: Patrick D. <pyo...@pd...> - 2013-04-03 17:14:58
|
As I'm trying to get my program fit for the future, I would like to avoid "downgrading" to 32 bit python. I tracked the problem a bit further: I replaced self.framebuffer_id = glGenFramebuffers(1); with fbo = ctypes.c_uint(1) OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, ctypes.byref(fbo)) self.framebuffer_id = int(fbo.value) I'm not sure if the code is ctype-wise correct but I think that doesn't make a real difference for the error: Traceback (most recent call last): ... File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 203, in __init__ OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, ctypes.byref(fbo)) File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", line 379, in __call__ return self( *args, **named ) WindowsError: exception: access violation writing 0xFFFFFFFFE812A790 Could anyone from the developers please help me track down the problem further? I'm very happy to assist in fixing this problem! Cheers, Patrick Am 03.04.2013 17:50, schrieb Cyrille Rossant: > I had a similar problem with a similar configuration and a similar > graphics card. I couldn't solve the problem, so I ended up removing my > whole 64 bits Python distribution and reinstalling everything with > Python 32 bits... and it worked. > > Cyrille > > > 2013/4/3 Patrick Dietrich <pyo...@pd... > <mailto:pyo...@pd...>> > > Hi everyone, > > I have a problem when calling glGenFramebuffers on Windows 7 64 bit: > > Traceback (most recent call last): > ... > File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 197, > in __init__ > self.framebuffer_id = glGenFramebuffers(1); > File "latebind.pyx", line 32, in > OpenGL_accelerate.latebind.LateBind.__call__ > (src\latebind.c:667) > File "wrapper.pyx", line 308, in > OpenGL_accelerate.wrapper.Wrapper.__call__ (s > rc\wrapper.c:5356) > File > "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", > line 379 > , in __call__ > return self( *args, **named ) > WindowsError: exception: access violation writing 0xFFFFFFFFEA94A760 > > My PyOpenGL version is 3.0.2, including PyOpenGL_accelerate 3.0.2. I > have installed both packages with the windows installers (AMD64 > versions). My graphics adaptor is an Intel HD Graphics 4000 for which > I'm using the newest drivers (version 9.17.10.2843). > > Calling bool(glGenFramebuffers) just before the call to > glGenFramebuffers returns True. I have also tried to use the extension > version glGenFramebuffersEXT but with the same result. > > What might be the problem and how can I work around it? > How can I access the low level C-routines of OpenGL? > > Cheers, > Patrick > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > <mailto:PyO...@li...> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > |
From: Cyrille R. <cyr...@gm...> - 2013-04-03 17:24:47
|
Do you have the possibility to test your program on another configuration? I had a program working perfectly well on multiple configurations (Windows, Mac, Linux, etc.), except a particular one (Windows 8 64 bits, Python 64 bits, Intel HD 3000). So this bug might be due to some interaction between the Intel Windows drivers and PyOpenGL/Python 64 bits. I fear that this bug may be very hard to fix (especially if the drivers contain a bug somewhere). How much RAM do you have? If you have an Intel HD card I suppose that you don't have so much memory that you absolutely need Python 64 bits (with 32 bits you're probably limited to ~4GB objects). Those who will really need a 64 bits distribution will probably have a better graphics card anyway and may be able to use your program. Cyrille 2013/4/3 Patrick Dietrich <pyo...@pd...> > > As I'm trying to get my program fit for the future, I would like to > avoid "downgrading" to 32 bit python. > > I tracked the problem a bit further: > > I replaced > > self.framebuffer_id = glGenFramebuffers(1); > > with > > fbo = ctypes.c_uint(1) > OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, > ctypes.byref(fbo)) > self.framebuffer_id = int(fbo.value) > > I'm not sure if the code is ctype-wise correct but I think that doesn't > make a real difference for the error: > > Traceback (most recent call last): > ... > File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 203, in > __init__ > OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, > ctypes.byref(fbo)) > File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", > line 379, in __call__ > return self( *args, **named ) > WindowsError: exception: access violation writing 0xFFFFFFFFE812A790 > > Could anyone from the developers please help me track down the problem > further? I'm very happy to assist in fixing this problem! > > Cheers, > Patrick > > > Am 03.04.2013 17:50, schrieb Cyrille Rossant: > > I had a similar problem with a similar configuration and a similar > > graphics card. I couldn't solve the problem, so I ended up removing my > > whole 64 bits Python distribution and reinstalling everything with > > Python 32 bits... and it worked. > > > > Cyrille > > > |
From: Cyrille R. <cyr...@gm...> - 2013-04-04 15:36:02
|
> 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 |
From: Ian M. <ia...@ge...> - 2013-04-04 15:41:34
|
Hi, Just a reminder; in my experience, Intel chipsets have extremely poor reliability and standards compliance with regard to graphics. Even things that ought to work don't necessarily. Writing a test program in C would be informative. Ian |
From: Chris B. - N. F. <chr...@no...> - 2013-04-04 15:56:25
|
On Wed, Apr 3, 2013 at 10:24 AM, Cyrille Rossant <cyr...@gm...> wrote: > How much RAM do you have? If you have an Intel HD card I suppose that you > don't have so much memory that you absolutely need Python 64 bits (with 32 > bits you're probably limited to ~4GB objects). actually 2GB on Windows, and I think that's for the whole process -- but that's still a lot for most applications. >> I replaced >> >> self.framebuffer_id = glGenFramebuffers(1); >> >> with >> >> fbo = ctypes.c_uint(1) >> OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, >> ctypes.byref(fbo)) >> self.framebuffer_id = int(fbo.value) >> >> I'm not sure if the code is ctype-wise correct but I think that doesn't >> make a real difference for the error: >> >> Traceback (most recent call last): >> ... >> File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 203, in >> __init__ >> OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(1, >> ctypes.byref(fbo)) >> File "C:\Python27\lib\site-packages\OpenGL\platform\baseplatform.py", >> line 379, in __call__ >> return self( *args, **named ) >> WindowsError: exception: access violation writing 0xFFFFFFFFE812A790 well, that is a bigger-than-32bit address -- I suppose it's possible that this is a 32/64 bit issue. Can you test it with 32 bit python? Even if you don't want to ultimatley go that route, it may give you a hint. Also, from teh ctypes docs: c_uint is a unsigned int you may have some issues there, an "int" is a really poorly defined type, and depending on the compiler, it may be 32 bits on 32bit systems, and 32 or 64 bit on 64 bit systems (and the MS compilers and gnu do it differently), so there could be some mis-match there. It's beyond me that C has survived this long with such soft defining of type sizes! Here's hoping that people start using the C99 defined size integer types sooner than later... (though from the looks of it, ctypes doesn't support those either...) Not sure this is any help, though. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Mike C. F. <mcf...@vr...> - 2013-04-04 17:31:52
|
On 13-04-04 11:55 AM, Chris Barker - NOAA Federal wrote: > On Wed, Apr 3, 2013 at 10:24 AM, Cyrille Rossant > <cyr...@gm...> wrote: ... > well, that is a bigger-than-32bit address -- I suppose it's possible > that this is a 32/64 bit issue. > > Can you test it with 32 bit python? Even if you don't want to > ultimatley go that route, it may give you a hint. > > Also, from teh ctypes docs: > > c_uint is a unsigned int > > you may have some issues there, an "int" is a really poorly defined > type, and depending on the compiler, it may be 32 bits on 32bit > systems, and 32 or 64 bit on 64 bit systems (and the MS compilers and > gnu do it differently), so there couldn be some mis-match there. > > It's beyond me that C has survived this long with such soft defining > of type sizes! Here's hoping that people start using the C99 defined > size integer types sooner than later... > > (though from the looks of it, ctypes doesn't support those either...) Actually ctypes *does* now support sized types: ctypes.c_int8 ctypes.c_int16 ctypes.c_int32 ctypes.c_int64 (this is on python 2.7.3 Linux 64-bit). I actually am using them while working on the EGL wrapper, and will likely switch to using them on the GL level too (since e.g. GLint is explicitly 32-bit, *not* platform specific). . ctypes.c_size_t is also pretty useful, and I will likely use that as appropriate. As for the original error, it *could* be that there's a problem with 64-bit windows there, but I'm a bit skeptical, as 64-bit Linux doesn't show any problems, and the test_core.py script actually generates a framebuffer during testing if glGenFrameBuffers is available. That's my very first smoke-test for the build working on any platform. Something to verify to debug the issue: * the address printed out as the access violation is *precisely* the same as the result of ctypes.addressof( variable ) when doing the raw API query if we're looking at different values, then we likely have the wrapper wrong (i.e. somehow it is changing the value passed in), if they are the same, then there's something preventing the writing to that address... which I don't have much to contribute... HTH, Mike |
From: Chris B. - N. F. <chr...@no...> - 2013-04-04 22:22:22
|
On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher <mcf...@vr...> wrote: > Actually ctypes *does* now support sized types: > > ctypes.c_int8 ctypes.c_int16 ctypes.c_int32 ctypes.c_int64 cool! I didn't see that in the docs I was looking at... > As for the original error, it *could* be that there's a problem with 64-bit > windows there, but I'm a bit skeptical, as 64-bit Linux doesn't show any > problems, and the test_core.py script actually generates a framebuffer > during testing if glGenFrameBuffers is available. That's my very first > smoke-test for the build working on any platform. well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and Windows (MSVC) gives you 23 bits for an "int", or something like that -- there is defiantly a difference in there somewhere (maybe it's long?) Anyway, I think it sure could be a non-issue on LInux, and kill you on windows. -Chris > Something to verify to debug the issue: > > the address printed out as the access violation is *precisely* the same as > the result of ctypes.addressof( variable ) when doing the raw API query > > if we're looking at different values, then we likely have the wrapper wrong > (i.e. somehow it is changing the value passed in), if they are the same, > then there's something preventing the writing to that address... which I > don't have much to contribute... > > HTH, > Mike > > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Mike C. F. <mcf...@vr...> - 2013-04-05 13:44:38
|
On 13-04-04 06:21 PM, Chris Barker - NOAA Federal wrote: > On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher > <mcf...@vr...> wrote: ... >> As for the original error, it *could* be that there's a problem with 64-bit >> windows there, but I'm a bit skeptical, as 64-bit Linux doesn't show any >> problems, and the test_core.py script actually generates a framebuffer >> during testing if glGenFrameBuffers is available. That's my very first >> smoke-test for the build working on any platform. > well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and > Windows (MSVC) gives you 23 bits for an "int", or something like that > -- there is defiantly a difference in there somewhere (maybe it's > long?) Anyway, I think it sure could be a non-issue on LInux, and kill > you on windows. I'm pretty sure we would have hit a 23-bit integer bug before this :) . All of PyOpenGL is using GLint = ctypes.c_int (which was taken from the Linux GL headers), and if my reading of the spec is correct, c_int is pretty close to what is meant (it should be c_long, as the minimum width is 32 bits, but I don't think there are any platforms we actually support which use 16-bit ints). That said, now that I read up on Windows, it seems that Win64 *does* use different conventions for long (doesn't expand it to 64-bit, apparently) vs. long long, and it is possible that we have something in there casting to an integer or long (instead of size_t/ptr types). There are a number of places where we have to do data-casts for pointers to/from integer-like types, and if something in those chains is of the wrong size, we might see an error. I spent an hour or so getting a development environment set up again on Windows (my other laptop died), so I may be able to track down the failure if I can get some more time today. I've got 64-bit Windows, but with AMD video card. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2013-04-05 15:10:54
|
On 13-04-05 09:44 AM, Mike C. Fletcher wrote: > On 13-04-04 06:21 PM, Chris Barker - NOAA Federal wrote: >> On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher >> <mcf...@vr...> wrote: > ... >>> As for the original error, it *could* be that there's a problem with 64-bit >>> windows there, but I'm a bit skeptical, as 64-bit Linux doesn't show any >>> problems, and the test_core.py script actually generates a framebuffer >>> during testing if glGenFrameBuffers is available. That's my very first >>> smoke-test for the build working on any platform. >> well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and >> Windows (MSVC) gives you 23 bits for an "int", or something like that >> -- there is defiantly a difference in there somewhere (maybe it's >> long?) Anyway, I think it sure could be a non-issue on LInux, and kill >> you on windows. > I'm pretty sure we would have hit a 23-bit integer bug before this :) . > All of PyOpenGL is using GLint = ctypes.c_int (which was taken from the > Linux GL headers), and if my reading of the spec is correct, c_int is > pretty close to what is meant (it should be c_long, as the minimum width > is 32 bits, but I don't think there are any platforms we actually > support which use 16-bit ints). I just now realized "23" was just mis-typed 32 (duh!) It turns out that, while I've been running test_core for 32-bit Python on Win64, I *haven't* been running it for 64-bit Python on Win64 (because I didn't have 64-bit Pygame or Numpy installed (now fixed)). Test core did fail due to the use of a Python int for an IntConstant where the value was 0xffffffff, (Python's int is apparently 32-bit on 64-bit Python, sigh). With that fixed (in bzr head), running: test_core.py Tests.test_fbo *does* run correctly on a Win64 machine with 64-bit Python, Pygame and Numpy. That is, I am using: fbo = glGenFramebuffers(1) and getting the expected frame buffer, then rendering something into it, then rendering a quad with that texture on it. Weird thing is, you couldn't even *import* PyOpenGL on 64-bit Python... so either it got broken rather recently or something fishy is occurring. I'm still seeing a test failure on GLU tessellation (possibly a pointer-size issue)... Patrick, could you test that the above test runs on your configuration? If it doesn't, we're likely looking at a platform or driver bug. If it does, then we'll need more investigation. You shouldn't actually need bzr head for that test, but feel free to use it if you'd prefer. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Cyrille R. <cyr...@gm...> - 2013-04-05 15:17:19
|
> It turns out that, while I've been running test_core for 32-bit Python > on Win64, I *haven't* been running it for 64-bit Python on Win64 > (because I didn't have 64-bit Pygame or Numpy installed (now fixed)). > Test core did fail due to the use of a Python int for an IntConstant > where the value was 0xffffffff, (Python's int is apparently 32-bit on > 64-bit Python, sigh). With that fixed (in bzr head), running: > > test_core.py Tests.test_fbo > > *does* run correctly on a Win64 machine with 64-bit Python, Pygame and > Numpy. That is, I am using: > > fbo = glGenFramebuffers(1) > > and getting the expected frame buffer, then rendering something into it, > then rendering a quad with that texture on it. > > Weird thing is, you couldn't even *import* PyOpenGL on 64-bit Python... > so either it got broken rather recently or something fishy is occurring. > > That's weird, I've been using PyOpenGL for Python 64 bits on Windows 64 bits for some time (at least a year). I've always been using Chris Gohlke's build. Cyrille |
From: Chris B. - N. F. <chr...@no...> - 2013-04-05 15:59:39
|
On Fri, Apr 5, 2013 at 8:10 AM, Mike C. Fletcher <mcf...@vr...> wrote: > I just now realized "23" was just mis-typed 32 (duh!) I thought you were riffing on my typo.... > Test core did fail due to the use of a Python int for an IntConstant > where the value was 0xffffffff, (Python's int is apparently 32-bit on > 64-bit Python, sigh). With that fixed (in bzr head), running: weird, it's 64 bit on OS-X -- at least sys.maxint seems to think so. 32 bit python: >>> sys.maxint 2147483647 64 bit python: >>> sys.maxint 9223372036854775807 But maybe this is because Window's "long" is 32 bit on 64 bit Windows... But thinks for digging into all this -- I, for one am still doing 32 bit Pyton on Windows, but have an app I want to port to 64bit soon. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Patrick D. <ma...@pd...> - 2013-04-06 10:03:21
Attachments:
test_core.py_output.txt
|
Am 05.04.2013 17:10, schrieb Mike C. Fletcher: > On 13-04-05 09:44 AM, Mike C. Fletcher wrote: >> On 13-04-04 06:21 PM, Chris Barker - NOAA Federal wrote: >>> On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher >>> <mcf...@vr...> wrote: >> ... >>>> As for the original error, it *could* be that there's a problem >>>> with 64-bit >>>> windows there, but I'm a bit skeptical, as 64-bit Linux doesn't >>>> show any >>>> problems, and the test_core.py script actually generates a framebuffer >>>> during testing if glGenFrameBuffers is available. That's my very >>>> first >>>> smoke-test for the build working on any platform. >>> well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and >>> Windows (MSVC) gives you 23 bits for an "int", or something like that >>> -- there is defiantly a difference in there somewhere (maybe it's >>> long?) Anyway, I think it sure could be a non-issue on LInux, and kill >>> you on windows. >> I'm pretty sure we would have hit a 23-bit integer bug before this . >> All of PyOpenGL is using GLint = ctypes.c_int (which was taken from the >> Linux GL headers), and if my reading of the spec is correct, c_int is >> pretty close to what is meant (it should be c_long, as the minimum width >> is 32 bits, but I don't think there are any platforms we actually >> support which use 16-bit ints). > I just now realized "23" was just mis-typed 32 (duh!) > > It turns out that, while I've been running test_core for 32-bit Python > on Win64, I *haven't* been running it for 64-bit Python on Win64 > (because I didn't have 64-bit Pygame or Numpy installed (now fixed)). > Test core did fail due to the use of a Python int for an IntConstant > where the value was 0xffffffff, (Python's int is apparently 32-bit on > 64-bit Python, sigh). With that fixed (in bzr head), running: > > test_core.py Tests.test_fbo > > *does* run correctly on a Win64 machine with 64-bit Python, Pygame and > Numpy. That is, I am using: > > fbo = glGenFramebuffers(1) > > and getting the expected frame buffer, then rendering something into it, > then rendering a quad with that texture on it. > > Weird thing is, you couldn't even *import* PyOpenGL on 64-bit Python... > so either it got broken rather recently or something fishy is occurring. > > I'm still seeing a test failure on GLU tessellation (possibly a > pointer-size issue)... > > Patrick, could you test that the above test runs on your configuration? > If it doesn't, we're likely looking at a platform or driver bug. If it > does, then we'll need more investigation. You shouldn't actually need > bzr head for that test, but feel free to use it if you'd prefer. > OK here is what I did: - uninstalled PyOpenGL_accelerate and PyOpenGL (using Windows Software-Removal) - downloaded PyOpenGL from bzr: "bzr branch lp:pyopengl" - built and installed PyOpenGL: "python setup.py build", "python setup.py install" - downloaded 64-bit pygame 1.9.2pre from http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame - executed "python test_core.py" in the test/ directory inside the pyopengl directory from bzr --> this fails (see attachment) I'm not sure if I have to change to the "head" distro somehow. Sorry I'm not familiar with bzr. I also tried to test my drivers with a simple C-Program. Unfortunately I can't get glew running with MinGW. But from what I read in the conversation MinGW may yield different results that MSVC anyway? Cheers, Patrick |
From: Patrick D. <pyo...@pd...> - 2013-04-06 15:56:12
Attachments:
test_core.py_output.txt
|
Am 05.04.2013 17:10, schrieb Mike C. Fletcher: > On 13-04-05 09:44 AM, Mike C. Fletcher wrote: >> On 13-04-04 06:21 PM, Chris Barker - NOAA Federal wrote: >>> On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher >>> <mcf...@vr...> wrote: >> ... >>>> As for the original error, it *could* be that there's a problem >>>> with 64-bit >>>> windows there, but I'm a bit skeptical, as 64-bit Linux doesn't >>>> show any >>>> problems, and the test_core.py script actually generates a framebuffer >>>> during testing if glGenFrameBuffers is available. That's my very >>>> first >>>> smoke-test for the build working on any platform. >>> well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and >>> Windows (MSVC) gives you 23 bits for an "int", or something like that >>> -- there is defiantly a difference in there somewhere (maybe it's >>> long?) Anyway, I think it sure could be a non-issue on LInux, and kill >>> you on windows. >> I'm pretty sure we would have hit a 23-bit integer bug before this . >> All of PyOpenGL is using GLint = ctypes.c_int (which was taken from the >> Linux GL headers), and if my reading of the spec is correct, c_int is >> pretty close to what is meant (it should be c_long, as the minimum width >> is 32 bits, but I don't think there are any platforms we actually >> support which use 16-bit ints). > I just now realized "23" was just mis-typed 32 (duh!) > > It turns out that, while I've been running test_core for 32-bit Python > on Win64, I *haven't* been running it for 64-bit Python on Win64 > (because I didn't have 64-bit Pygame or Numpy installed (now fixed)). > Test core did fail due to the use of a Python int for an IntConstant > where the value was 0xffffffff, (Python's int is apparently 32-bit on > 64-bit Python, sigh). With that fixed (in bzr head), running: > > test_core.py Tests.test_fbo > > *does* run correctly on a Win64 machine with 64-bit Python, Pygame and > Numpy. That is, I am using: > > fbo = glGenFramebuffers(1) > > and getting the expected frame buffer, then rendering something into it, > then rendering a quad with that texture on it. > > Weird thing is, you couldn't even *import* PyOpenGL on 64-bit Python... > so either it got broken rather recently or something fishy is occurring. > > I'm still seeing a test failure on GLU tessellation (possibly a > pointer-size issue)... > > Patrick, could you test that the above test runs on your configuration? > If it doesn't, we're likely looking at a platform or driver bug. If it > does, then we'll need more investigation. You shouldn't actually need > bzr head for that test, but feel free to use it if you'd prefer. > OK here is what I did: - uninstalled PyOpenGL_accelerate and PyOpenGL (using Windows Software-Removal) - downloaded PyOpenGL from bzr: "bzr branch lp:pyopengl" - built and installed PyOpenGL: "python setup.py build", "python setup.py install" - downloaded 64-bit pygame 1.9.2pre from http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame - executed "python test_core.py" in the test/ directory inside the pyopengl directory from bzr --> this fails (see attachment) I'm not sure if I have to change to the "head" distro somehow. Sorry I'm not familiar with bzr. I also tried to test my drivers with a simple C-Program. Unfortunately I can't get glew running with MinGW. But from what I read in the conversation MinGW may yield different results that MSVC anyway? Cheers, Patrick |
From: Mike C. F. <mcf...@vr...> - 2013-04-06 20:26:56
|
On 13-04-06 11:55 AM, Patrick Dietrich wrote: ... > OK here is what I did: > > - uninstalled PyOpenGL_accelerate and PyOpenGL (using Windows > Software-Removal) > - downloaded PyOpenGL from bzr: "bzr branch lp:pyopengl" > - built and installed PyOpenGL: "python setup.py build", "python > setup.py install" > - downloaded 64-bit pygame 1.9.2pre from > http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame > - executed "python test_core.py" in the test/ directory inside the > pyopengl directory from bzr > --> this fails (see attachment) > > I'm not sure if I have to change to the "head" distro somehow. Sorry > I'm not familiar with bzr. Nope, that's head already. > I also tried to test my drivers with a simple C-Program. Unfortunately > I can't get glew running with MinGW. But from what I read in the > conversation MinGW may yield different results that MSVC anyway? It would tell us if it's hardware/drivers. I followed the same steps, and on an Intel Graphics Win64 Windows 7 machine this time... and got 0 errors for the test_core test suite (on bzr head). The values you're seeing in the access violation reports *look* wrong, that is, the first 4 bytes are all 1's. If you could print out: v = ctypes.c_uint() print ctypes.addressof( v ) for a value that's producing the error, it would at least let us know if the address is wrong before it goes into the wrapping process. If the all-ones addresses are "real", then maybe we're seeing a driver issue with the greater than 2GB addresses (maybe drivers coded for 32-bit mode?) If they are an artefact of the conversion process, then we can use pdb to step through the wrapping process one step at a time to try to figure out where the conversion gets messed up. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Patrick D. <pyo...@pd...> - 2013-04-08 08:11:50
|
Am 06.04.2013 22:26, schrieb Mike C. Fletcher: > On 13-04-06 11:55 AM, Patrick Dietrich wrote: > ... >> OK here is what I did: >> >> - uninstalled PyOpenGL_accelerate and PyOpenGL (using Windows >> Software-Removal) >> - downloaded PyOpenGL from bzr: "bzr branch lp:pyopengl" >> - built and installed PyOpenGL: "python setup.py build", "python >> setup.py install" >> - downloaded 64-bit pygame 1.9.2pre from >> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame >> - executed "python test_core.py" in the test/ directory inside the >> pyopengl directory from bzr >> --> this fails (see attachment) >> >> I'm not sure if I have to change to the "head" distro somehow. Sorry >> I'm not familiar with bzr. > Nope, that's head already. >> I also tried to test my drivers with a simple C-Program. Unfortunately >> I can't get glew running with MinGW. But from what I read in the >> conversation MinGW may yield different results that MSVC anyway? > It would tell us if it's hardware/drivers. > > I followed the same steps, and on an Intel Graphics Win64 Windows 7 > machine this time... and got 0 errors for the test_core test suite (on > bzr head). The values you're seeing in the access violation reports > *look* wrong, that is, the first 4 bytes are all 1's. If you could > print out: > > v = ctypes.c_uint() > print ctypes.addressof( v ) > > for a value that's producing the error, it would at least let us know if > the address is wrong before it goes into the wrapping process. If the > all-ones addresses are "real", then maybe we're seeing a driver issue > with the greater than 2GB addresses (maybe drivers coded for 32-bit > mode?) If they are an artefact of the conversion process, then we can > use pdb to step through the wrapping process one step at a time to try > to figure out where the conversion gets messed up. > > Take care, > Mike > So here is the code I tested: print 'ctypes.addressof( OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT ): %X' % ctypes.addressof( OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT ) fbo = ctypes.c_uint(1) print 'ctypes.addressof(fbo): %X' % ctypes.addressof(fbo) one = ctypes.c_int(1) OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(one, ctypes.byref(fbo)) And this is the correspoinding output: ctypes.addressof( OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT ): 7E7C710 ctypes.addressof(fbo): 7E98F10 Traceback (most recent call last): File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 315, in OnPaint self.main_canvas = CanvasLayer( self.viewport_width, self.viewport_height ) File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 205, in __init__ OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(one, ctypes.byref(fbo)) WindowsError: exception: access violation writing 0xFFFFFFFFEBAFA790 It seems to me that something goes wrong in the native routines. Could this be a bug when fetching the routines? Cheers, Patrick PS: Some things I tested for my system: >>> v = ctypes.c_uint() >>> ctypes.addressof( v ) 37067024L >>> ctypes.c_size_t() c_ulonglong(0L) >>> ctypes.c_uint() c_ulong(0L) >>> ctypes.c_int() c_long(0) >>> ctypes.c_uint32() c_ulong(0L) >>> ctypes.c_int32() c_long(0) >>> ctypes.c_uint64() c_ulonglong(0L) >>> ctypes.c_int64() c_longlong(0L) >>> |