pyopengl-users — Discussion of all PyOpenGL matters.

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

[Mike C. F. <mcf...@vr...>]

On 13-04-15 10:05 PM, David Vierra wrote:
...
>
> Sorry, I should have added that changing it to this line makes it work
> for me:
>
>     OpenGL.wglGetProcAddress.restype = ctypes.c_void_p
>
> Also, test_core.py runs without any errors after this change is made.
Thanks David, head is updated.

Enjoy,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Mike C. F. <mcf...@vr...>]

On 13-04-14 04:43 PM, Matt Williams wrote:
> On 14 April 2013 16:05, Ian Mallett <ia...@ge...> wrote:
>> Pass it binary strings.
> If I do that with:
>
> VERTEX_SHADER = shaders.compileShader(b"""
>      #version 130
>
>      void main()
>      {
>      }
>      """, GL_VERTEX_SHADER)
>
> then it still works correctly on Python 2.7 but with Python 3.3 it errors with:
The above code (with or without the b) works with Python 2.7, 3.2 and 
3.3 on Ubuntu 64-bit with fglrx drivers when using bzr head. bzr head 
*also* for the first time, can run test_core.py on all of those 
platforms (when numpy and pygame are installed), however, I don't see 
anything in the changes I made which should have caused the error you saw.

If you can test on bzr head, that would let me know whether we're 
looking at something already fixed, or a continuing bug.

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

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

[David V. <cod...@ha...>]

On 4/15/2013 3:55 PM, David Vierra wrote:
> On 4/15/2013 3:30 PM, Mike C. Fletcher wrote:
>
>> It also didn't cause problems on my 64-bit Windows 7, and it seems
>> correct, the return type *should* be a void pointer.  I gather it was
>> working for the other drivers because the next 4 bytes were always NULL
>> with the other drivers.
>>
>> bzr head has the fix.
>>
>> HTH,
>> Mike
> Thanks Mike!
>
> But I'm afraid bzr head is slightly broken ;)
>
>     File "c:\Users\Rio\Documents\src\pyopengl\OpenGL\platform\win32.py",
> line 67, in Win32Platform
>       getExtensionProcedure.restype = ctypes.c_void_p
>
> AttributeError: 'staticmethod' object has no attribute 'restype'
>
>
>

Sorry, I should have added that changing it to this line makes it work 
for me:

   OpenGL.wglGetProcAddress.restype = ctypes.c_void_p

Also, test_core.py runs without any errors after this change is made.

- David Vierra

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

[David V. <cod...@ha...>]

On 4/15/2013 3:30 PM, Mike C. Fletcher wrote:
> On 13-04-14 04:37 PM, David Vierra wrote:
>> On 4/14/2013 10:15 AM, Patrick Dietrich wrote:
>>> Am 13.04.2013 03:50, schrieb David Vierra:
>>>> In OpenGL/platform/baseplatform.py, constructFunction calls
>>>> self.getExtensionProcedure and gets a small negative number as a result.
>>>> I looked at getExtensionProcedure and traced it back to the
>>>> wglGetProcAddress that is implicitly created in
>>>> OpenGL/platform/win32.py. This wglGetProcAddress is a _FuncPtr whose
>>>> restype attribute is ctypes.c_long.
>>>>
>>>> If I add another line to OpenGL/platform/win32.py after the
>>>> `getExtensionProcedure = ` line, that says:
>>>>
>>>> OpenGL.wglGetProcAddress.restype = ctypes.c_void_p
>>>>
>>> I did the same thing and it fixed the problem with glGenFramebuffers,
>>> too! Thanks a lot David!
>>> Is this a fix which can be added to the official distribution or will it
>>> cause problems on other systems?
>> It did not cause problems with my 32-bit Python, at least. I strongly
>> doubt it would cause any problems on other (non-Windows) systems since
>> the change is only made in win32.py. The fix changes the result type of
>> one function pointer, but this hints strongly that the underlying
>> problem is that the default result type for ctypes funcptrs, on 64-bit
>> Python for Windows, is only 32 bits long.
> It also didn't cause problems on my 64-bit Windows 7, and it seems
> correct, the return type *should* be a void pointer.  I gather it was
> working for the other drivers because the next 4 bytes were always NULL
> with the other drivers.
>
> bzr head has the fix.
>
> HTH,
> Mike

Thanks Mike!

But I'm afraid bzr head is slightly broken ;)

   File "c:\Users\Rio\Documents\src\pyopengl\OpenGL\platform\win32.py", 
line 67, in Win32Platform
     getExtensionProcedure.restype = ctypes.c_void_p

AttributeError: 'staticmethod' object has no attribute 'restype'

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

[Mike C. F. <mcf...@vr...>]

On 13-04-14 04:37 PM, David Vierra wrote:
> On 4/14/2013 10:15 AM, Patrick Dietrich wrote:
>> Am 13.04.2013 03:50, schrieb David Vierra:
>>> In OpenGL/platform/baseplatform.py, constructFunction calls
>>> self.getExtensionProcedure and gets a small negative number as a result.
>>> I looked at getExtensionProcedure and traced it back to the
>>> wglGetProcAddress that is implicitly created in
>>> OpenGL/platform/win32.py. This wglGetProcAddress is a _FuncPtr whose
>>> restype attribute is ctypes.c_long.
>>>
>>> If I add another line to OpenGL/platform/win32.py after the
>>> `getExtensionProcedure = ` line, that says:
>>>
>>> OpenGL.wglGetProcAddress.restype = ctypes.c_void_p
>>>
>> I did the same thing and it fixed the problem with glGenFramebuffers,
>> too! Thanks a lot David!
>> Is this a fix which can be added to the official distribution or will it
>> cause problems on other systems?
> It did not cause problems with my 32-bit Python, at least. I strongly
> doubt it would cause any problems on other (non-Windows) systems since
> the change is only made in win32.py. The fix changes the result type of
> one function pointer, but this hints strongly that the underlying
> problem is that the default result type for ctypes funcptrs, on 64-bit
> Python for Windows, is only 32 bits long.
It also didn't cause problems on my 64-bit Windows 7, and it seems 
correct, the return type *should* be a void pointer.  I gather it was 
working for the other drivers because the next 4 bytes were always NULL 
with the other drivers.

bzr head has the fix.

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Chris B. - N. F. <chr...@no...>]

I'm not using py3, but maybe you need to encode the string into a
bytes object ASCII.

-Chris
On Apr 14, 2013, at 1:44 PM, Matt Williams <li...@mi...> wrote:

> On 14 April 2013 16:05, Ian Mallett <ia...@ge...> wrote:
>> Pass it binary strings.
>
> If I do that with:
>
> VERTEX_SHADER = shaders.compileShader(b"""
>    #version 130
>
>    void main()
>    {
>    }
>    """, GL_VERTEX_SHADER)
>
> then it still works correctly on Python 2.7 but with Python 3.3 it errors with:
>
> RuntimeError: ('Shader compile failure (0):\n0(1) : error C0125:
> integer constant overflow\n0(1) : error C0000: syntax error,
> unexpected unsigned integer constant at token "<uint-const>"\n', [10,
> 9, 35, 118, 101, 114, 115, 105, 111, 110, 32, 49, 51, 48, 10, 9, 10,
> 9, 118, 111, 105, 100, 32, 109, 97, 105, 110, 40, 41, 10, 9, 123, 10,
> 9, 125, 10, 9], GL_VERTEX_SHADER)
>
> So it looks to be passing a list of integers referring to the correct
> ASCII characters.
>
> The Python source file itself is utf-8 encoded but since I'm only
> using the ASCII range of characters, it's the same as if it were ASCII
> encoded.
>
> I have the same problem if I do:
>
> VERTEX_SHADER = shaders.compileShader("""
>    #version 130
>
>    void main()
>    {
>    }
>    """.encode('ascii'), GL_VERTEX_SHADER)
>
> with an identical error.
>
> Regards,
> Matt Williams
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Matt W. <li...@mi...>]

On 14 April 2013 16:05, Ian Mallett <ia...@ge...> wrote:
> Pass it binary strings.

If I do that with:

VERTEX_SHADER = shaders.compileShader(b"""
    #version 130

    void main()
    {
    }
    """, GL_VERTEX_SHADER)

then it still works correctly on Python 2.7 but with Python 3.3 it errors with:

RuntimeError: ('Shader compile failure (0):\n0(1) : error C0125:
integer constant overflow\n0(1) : error C0000: syntax error,
unexpected unsigned integer constant at token "<uint-const>"\n', [10,
9, 35, 118, 101, 114, 115, 105, 111, 110, 32, 49, 51, 48, 10, 9, 10,
9, 118, 111, 105, 100, 32, 109, 97, 105, 110, 40, 41, 10, 9, 123, 10,
9, 125, 10, 9], GL_VERTEX_SHADER)

So it looks to be passing a list of integers referring to the correct
ASCII characters.

The Python source file itself is utf-8 encoded but since I'm only
using the ASCII range of characters, it's the same as if it were ASCII
encoded.

I have the same problem if I do:

VERTEX_SHADER = shaders.compileShader("""
    #version 130

    void main()
    {
    }
    """.encode('ascii'), GL_VERTEX_SHADER)

with an identical error.

Regards,
Matt Williams

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

[David V. <cod...@ha...>]

On 4/14/2013 10:15 AM, Patrick Dietrich wrote:
> Am 13.04.2013 03:50, schrieb David Vierra:
>> In OpenGL/platform/baseplatform.py, constructFunction calls
>> self.getExtensionProcedure and gets a small negative number as a result.
>> I looked at getExtensionProcedure and traced it back to the
>> wglGetProcAddress that is implicitly created in
>> OpenGL/platform/win32.py. This wglGetProcAddress is a _FuncPtr whose
>> restype attribute is ctypes.c_long.
>>
>> If I add another line to OpenGL/platform/win32.py after the
>> `getExtensionProcedure = ` line, that says:
>>
>> OpenGL.wglGetProcAddress.restype = ctypes.c_void_p
>>
> I did the same thing and it fixed the problem with glGenFramebuffers,
> too! Thanks a lot David!
> Is this a fix which can be added to the official distribution or will it
> cause problems on other systems?

It did not cause problems with my 32-bit Python, at least. I strongly 
doubt it would cause any problems on other (non-Windows) systems since 
the change is only made in win32.py. The fix changes the result type of 
one function pointer, but this hints strongly that the underlying 
problem is that the default result type for ctypes funcptrs, on 64-bit 
Python for Windows, is only 32 bits long.

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

[Patrick D. <pyo...@pd...>]

Am 13.04.2013 03:50, schrieb David Vierra:
> In OpenGL/platform/baseplatform.py, constructFunction calls
> self.getExtensionProcedure and gets a small negative number as a result.
> I looked at getExtensionProcedure and traced it back to the
> wglGetProcAddress that is implicitly created in
> OpenGL/platform/win32.py. This wglGetProcAddress is a _FuncPtr whose
> restype attribute is ctypes.c_long.
>
> If I add another line to OpenGL/platform/win32.py after the
> `getExtensionProcedure = ` line, that says:
>
> OpenGL.wglGetProcAddress.restype = ctypes.c_void_p
>
I did the same thing and it fixed the problem with glGenFramebuffers, 
too! Thanks a lot David!
Is this a fix which can be added to the official distribution or will it 
cause problems on other systems?

Cheers,
Patrick

Re: [PyOpenGL-Users] Shader doesn't compile with Python 3

[Ian M. <ia...@ge...>]

Pass it binary strings.

[PyOpenGL-Users] Shader doesn't compile with Python 3

[Matt W. <li...@mi...>]

Hi all,

I'm really enjoying using PyOpenGL. I've just switched over to using
Python3 but I've hit a problem with compiling my shaders. As an example,
consider this code:

---------- test.py

from OpenGL.GL import shaders, GL_VERTEX_SHADER

import pygame
screen = pygame.display.set_mode((800, 800), pygame.OPENGL)

VERTEX_SHADER = shaders.compileShader("""
    #version 130

    void main()
    {
    }
    """, GL_VERTEX_SHADER)

----------

I'm running all this on Linux (openSUSE 12.3) with the following
configuration:

GL_RENDERER: GeForce GTX 560 Ti/PCIe/SSE2
GL_VERSION: 4.3.0 NVIDIA 313.30
GL_SHADING_LANGUAGE_VERSION: 4.30 NVIDIA via Cg compiler

If I run this code with 'python test.py' then it runs fine (briefly flashes
a window without complaint). However, when running under Python 3 with
'python3 test.py' it gives the following error:

----------

Traceback (most recent call last):
  File "./test.py", line 14, in <module>
    """, GL_VERTEX_SHADER)
  File
"/home/matt/.local/lib/python3.3/site-packages/OpenGL/GL/shaders.py", line
233, in compileShader
    shaderType,
RuntimeError: ('Shader compile failure (0):\n0(1) : error C0130: invalid
character literal\n0(1) : error C0000: syntax error, unexpected special
error tag, expecting "::" at token "<error>"\n0(1) : error C0130: invalid
character literal\n', [b'\n\t#version 130\n\t\n\tvoid
main()\n\t{\n\t}\n\t'], GL_VERTEX_SHADER)

----------

Given that the first error is 'invalid character literal', I'm assuming
that this is an encoding problem. It looks like (as far as I can tell)
PyOpenGL is sending an ASCII-encoded byte string but maybe that's not what
is expected?

Is anyone else seeing this problem or can reproduce this? Or does anyone
have an idea of the reason it's happening or a fix for it?

Regards,
Matt Williams

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

[David V. <cod...@ha...>]

My best idea is that the Intel GPU Drivers on 64 bit systems will prefer 
to load at memory addresses above 4 gigabytes, while the other drivers 
will load at lower memory addresses. This is pretty much what I found, 
since the valid addresses returned by wglGetProcAddress on my system are 
above 4 gigs.

On 4/13/2013 9:20 AM, Cyrille Rossant wrote:
>
>     So, my conclusion is that the function pointer to
>     wglGetProcAddress used
>     by the PyOpenGL's win32 platform module has the wrong result type
>     (it is
>     c_long which is only 32 bits when it should be c_void_p which is
>     64 bits
>     long).
>
>
> Do you have an idea why this bug seems to appear only on Intel GPUs?
>
> Cyrille

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

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

> So, my conclusion is that the function pointer to wglGetProcAddress used
> by the PyOpenGL's win32 platform module has the wrong result type (it is
> c_long which is only 32 bits when it should be c_void_p which is 64 bits
> long).
>

Do you have an idea why this bug seems to appear only on Intel GPUs?

Cyrille

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

[David V. <cod...@ha...>]

Hello, everyone!

I'm having a very similar problem to this one and I'd like to help out 
however I can.

I am on Windows 7, I have an Intel HD 4000 chipset, and I have both 
32-bit and 64-bit version of Python installed. I get:

 > "WindowsError: exception: access violation writing 0xFFFFFFFFE1FEFA20"

when I call GL.glActiveTexture(GL.GL_TEXTURE0). I can reproduce this 
with a very small sample program that only calls pygame.set_mode and 
glActiveTexture, and confirm that the crash only happens with the 64-bit 
Python.


Also, while I did not write a little C program, I can observe something 
that tells me the graphics drivers aren't outright broken: I can play 
Minecraft on top of a 64-bit Java runtime, and Minecraft has no problems 
calling glActiveTexture (via LWJGL, which has to be calling the C natives).

glActiveTexture is part of the OpenGL 1.3 feature set. Someone mentioned 
that features not part of GL 1.1 were being loaded from the wrong DLL 
(or something?):

> 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.

So, I looked at a few function objects (GL.glEnable, GL.glTexImage, 
GL.glActiveTexture and others) using the 64-bit debugger. Each one has a 
DLL attribute which references the open DLL handle, and every one I 
looked at refers to "C:\Windows\System32\opengl.dll". I also noticed 
that different functions had different object types:

glActiveTexture = <OpenGL.platform.baseplatform.glActiveTexture object 
at 0x03DCC5F0>
glGenFramebuffers = <OpenGL.platform.baseplatform.glGenFramebuffers 
object at 0x03E695F8>
glEnable = <WinFunctionType object at 0x03CD27B0>
glTexImage2d = <ctypes.glTexImage2D object at 0x03DB28A0>

I wondered what the difference is, stepped around in the debugger some 
more, and found out the first two are "null function" placeholders. They 
are null at first because a GL context is required to check for 
extensions and GL versions. I stepped through glActiveTexture's lazy 
loading the first time it is called, and I think I found out what the 
problem is.

In OpenGL/platform/baseplatform.py, constructFunction calls 
self.getExtensionProcedure and gets a small negative number as a result. 
I looked at getExtensionProcedure and traced it back to the 
wglGetProcAddress that is implicitly created in 
OpenGL/platform/win32.py. This wglGetProcAddress is a _FuncPtr whose 
restype attribute is ctypes.c_long.

If I add another line to OpenGL/platform/win32.py after the 
`getExtensionProcedure = ` line, that says:

OpenGL.wglGetProcAddress.restype = ctypes.c_void_p

Then the result of getExtensionProcedure is now a longer positive 
number, and better yet the call to glActiveTexture doesn't crash with an 
Access Violation any more!

So, my conclusion is that the function pointer to wglGetProcAddress used 
by the PyOpenGL's win32 platform module has the wrong result type (it is 
c_long which is only 32 bits when it should be c_void_p which is 64 bits 
long).

Hope this helps,

- David Vierra

Re: [PyOpenGL-Users] ANGLE in PyOpenGL

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

2013/4/9 Mike C. Fletcher <mcf...@vr...>

> On 13-04-08 03:58 PM, Cyrille Rossant wrote:
> > Hi,
> >
> > Is it conceivable to implement ANGLE
> > <https://code.google.com/p/angleproject/> in PyOpenGL? Windows users
> > frequently have broken OpenGL implementations, even with the GPU
> > manufacturer drivers correctly installed. Windows sometimes insists
> > for using its native OpenGL 1.1 implementation instead of the GPU
> > driver implementation, and it can be quite hard for some users to fix
> > this.
> >
> > ANGLE allows to translate OpenGL ES calls to DirectX calls. That's how
> > WebGL works in Chrome and Firefox on Windows. How complicated would it
> > be to integrate it in PyOpenGL?
> Well, as of right now, ES and EGL are just spike tests in PyOpenGL. Once
> they are working, it sounds like it might be possible to make ANGLE
> work.  You'd need a layer that enabled ANGLE in your application, it
> looks like it basically just has some EGL entry points that let you
> connect to a Win32 Direct3D context... so you likely need some stubs to
> make that context available before you start doing the EGL operations.
> It doesn't really seem like something that should be *in* PyOpenGL,
> though.  That is, you'd expect to see the EGL, and OpenGL-ES code in
> PyOpenGL and then a small shim that worked with ANGLE (likely having to
> deliver the ANGLE libraries with it).
>

Thanks. It would be nice if there were some documentation about how to do
that when PyOpenGL is ready for it. Developers using PyOpenGL for their
applications could then create a Windows package bundling ANGLE and the
appropriate glue code for telling PyOpenGL to use this layer.

Cyrille

Re: [PyOpenGL-Users] ANGLE in PyOpenGL

[Mike C. F. <mcf...@vr...>]

On 13-04-08 03:58 PM, Cyrille Rossant wrote:
> Hi,
>
> Is it conceivable to implement ANGLE 
> <https://code.google.com/p/angleproject/> in PyOpenGL? Windows users 
> frequently have broken OpenGL implementations, even with the GPU 
> manufacturer drivers correctly installed. Windows sometimes insists 
> for using its native OpenGL 1.1 implementation instead of the GPU 
> driver implementation, and it can be quite hard for some users to fix 
> this.
>
> ANGLE allows to translate OpenGL ES calls to DirectX calls. That's how 
> WebGL works in Chrome and Firefox on Windows. How complicated would it 
> be to integrate it in PyOpenGL?
Well, as of right now, ES and EGL are just spike tests in PyOpenGL. Once 
they are working, it sounds like it might be possible to make ANGLE 
work.  You'd need a layer that enabled ANGLE in your application, it 
looks like it basically just has some EGL entry points that let you 
connect to a Win32 Direct3D context... so you likely need some stubs to 
make that context available before you start doing the EGL operations.  
It doesn't really seem like something that should be *in* PyOpenGL, 
though.  That is, you'd expect to see the EGL, and OpenGL-ES code in 
PyOpenGL and then a small shim that worked with ANGLE (likely having to 
deliver the ANGLE libraries with it).

HTH,
Mike

[PyOpenGL-Users] ANGLE in PyOpenGL

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

Hi,

Is it conceivable to implement ANGLE <
https://code.google.com/p/angleproject/> in PyOpenGL? Windows users
frequently have broken OpenGL implementations, even with the GPU
manufacturer drivers correctly installed. Windows sometimes insists for
using its native OpenGL 1.1 implementation instead of the GPU driver
implementation, and it can be quite hard for some users to fix this.

ANGLE allows to translate OpenGL ES calls to DirectX calls. That's how
WebGL works in Chrome and Firefox on Windows. How complicated would it be
to integrate it in PyOpenGL?

Cyrille Rossant

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

[Patrick D. <pyo...@pd...>]

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)
 >>>

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

[Mike C. F. <mcf...@vr...>]

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

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

[Patrick D. <pyo...@pd...>]

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

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

[Patrick D. <ma...@pd...>]

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

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

[Chris B. - N. F. <chr...@no...>]

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...

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

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

> 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

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

[Mike C. F. <mcf...@vr...>]

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

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

[Mike C. F. <mcf...@vr...>]

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