-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS X with mesalib-glw: import pi3d fails #190
Comments
For me the mesa libraries installed via brew are in |
@John-P Hi, does pi3d run OK on OS X if you change pi3d/constants/init.py? Did you try the ctypes.util find_library() as in _linux? There is also the PLATFORM constant that needs to be set for the correct drawing surface to be loaded in DisplayOpenGL.py What happens if you change the entry in _PLATFORMS to I'm really keen to get this working but it will be tricky without a mac to test it on. If you're willing to try things I would be happy to help in whatever way I can. |
@paddywwoof I'm happy to help get pi3d running on OS X. I'll take another look tonight and change my pi3d/constants/init.py to see if I can get it going. |
OK. So looks like mesa is not needed on OS X (also the brew formula doesn't install the gles libraries) but xquartz is. OpenGL|ES libraries are located at:
After googling apparently the OS X equivalent of EGL is CGL which I think is part of the OpenGL Library. When trying to run a simple scene with a camera and a sphere I get this:
Currently stumped |
@John-P That's great stuff. Thanks for struggling on with this. To translate the error messages: line 2409 in xlib.py is the first line where a function is assigned from the ctypes loaded dll/shared object libX11 which, in turn, should have been loaded in line 7 and 8
So it looks like the xquartz library isn't known as X11 on the mac. Or it might need a hard coded path, presumably it's a .dylib file like the EGL and GLESv2 ones. (There are a few comments about the symlinks being scrambled by os upgrades but not relevant if you've just installed xquarts) Alternatively if you can get pygame running on the mac (which looks quite an effort http://pygame.org/wiki/macintosh ) then you can set an argument use_pygame=True in Display.create() and the X11 stuff is handled by pygame. |
@paddywwoof Pygame doesn't look too bad to install. Would be nice to get pi3d working with xquartz though. Will investigate and see if |
Hi! I'm also highly interested in running pi3d on OS X. I have made the modifications suggested in your conversation so far. Additionally, I modified line 8 in xlib.py to:
This seems to solve the
|
Hi, yes I would really like to get pi3d running on OSX too but I am not allowed to touch my wife's mac on pain of death (or worse). I looks to me like the error message is due to the ctypes shared library openegl not containing the function eglGetDisplay. Looking up at John-P's post that seems to be loaded with /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib and I would expect it to use libEGL.dylib assuming it's following the same naming convention of linux and windows. Can you search on your system and see if there's a libEGL library anywhere? |
Hi! I'm running macOS 10.12.1 and I can not find libEGL anywhere ...
but according to the site above, the call may be something like |
Hi, The import definition for openegl is in pi3d/constants/init.py where you added the new function _darwin() as per John-P's post above. But I'm not sure that the required libraries are loaded with xquartz. If you searched you computer for the file libEGL* and it wasn't there then that probably means you need to get it from somewhere. Did you install the mesalib-gwl brew? It looks from the docs that EGL support isn't included by default so you might need to compile your own. see Alternatively you could try a different tack by using ANGLE which seems to be quite actively supported (google etc) - but may have some bits to complete w.r.t. mac. |
Hi again!
The build ran without a problem and I got
|
btw. all of my results are also true for OS X 10.11.6. |
Hi, well that's good news in some ways as python seems to be loading the libEGL library and managing to find the various functions called down to line 79. However one or other of them is not managing to come up with the goods. I don't know if it's relevant but I had similar symptoms trying to get pi3d working with windows, specifically on some set-ups, especially when using 64 bit python. If you look in
So that would also happen for Also, I will attach the script I used when trying to debug what wasn't working while trying to get pi3d working on windows just in case you can glean a bit more info using it. |
Hi! I don't have much time in the next view days, but I made the modifications to
I also ran your
|
I'm using Python 3.7.5 and macOS 10.15.2 with pi3d 2.34 I'm using xquartz 2.7.11 installed with brew. On import of pi3d I get this:
Since it is now 2020 I'd be happy to pick up the thread on this if someone is willing to offer some advice. |
Ryan, it would be great to get pi3d working on mac and your offer of help is great but it might be quite hard to work through the issues remotely. That error indicates that the first function to be used from the ctypes loaded library X11 isn't there. On my linux laptop (or raspberry pi with X11 installed) $ python3
>>> import ctypes
>>> from ctypes.util import find_library
>>> x11_name = find_library('X11')
>>> x11_name
'libX11.so.6'
>>> libX11 = ctypes.CDLL(x11_name)
>>> libX11.XLoadQueryFont
<_FuncPtr object at 0x7f1ef9f62818> See what you get on the mac with xquartz. You could try searching your machine for files with libX11 in their name. If you compile xquartz then the shared objects might have been created but not registered (don't really know that stuff works on darwin). Paddy PS, I am gradually working up a version of pi3d wrapping a Rust implementation here https://github.com/paddywwoof/rust_pi3d.git That system uses the slightly abstracted sdl2 and gl libraries and, hopefully, will just work on more OSs... |
Ah. I didn't realize this was more of a feature request then a bug report. On my system I've got
>>> import ctypes
>>> from ctypes.util import find_library
>>> x11_name = find_library('X11')
>>> x11_name
'/opt/X11/lib/libX11.dylib'
>>> libX11 = ctypes.CDLL(x11_name)
>>> libX11.XLoadQueryFont
<_FuncPtr object at 0x1092b66d0> At this point the error is now:
This is caused by the loader in my case being pi3d/pi3d/constants/__init__.py Lines 159 to 160 in 06057fa
Uh oh... :) |
Well that's actually progress. The function should have darwin specific code but if the required dylibs can be loaded on the basis of it being X11 there might not need to be anything in there. Ie it could just |
That would be nice!
|
it's libEGL.dylib but googling that sounds like it might not be generally used on mac. Someone suggests downloading from https://moltengl.com/downloads/ (2nd link GLES2 etc) it should then be found by find_library if you put it somewhere on the sys.path i.e. in the current directory you run python from. The alternative route might be to use GLX if that's available (check find_library('GLX') etc) If this library is there then you would need to add the argument use_glx=True to the Display.create() fn Further thoughts scanning back through this thread. You could try using libGL.dylib something along the lines of (though I haven't been able to see what functions are supposed to be in libGL.dylib) def _darwin():
from ctypes.util import find_library
platform = PLATFORM_OSX
bcm = None
opengles = _load_library(find_library("GLESv2"))
openegl = _load_library(find_library("GL"))
return platform, bcm, openegl, opengles # opengles now determined by platform |
Well it seems I don't have GLX either. Replacing
|
I think I may have done it. I changed def _darwin():
pass to def _darwin():
return _linux() I then installed moltengl's library and putting them in my path ('/usr/local/lib`) However this got me this error on running I then when to System Preferences > Security & Privacy and clicked on "Allow Anyway" in General It now imports fine! I am getting other errors though. To narrow these down could I ask what the "hello world" is for this code? EDIT: |
Hi, that all sounds quite hopeful, some kind of progress anyway. I doubted that the GL dylib would have all the EGL functions - doesn't on this linux either. When you say nothing on the screen, do you not even get an X11 window popping up? Can you test whether xquartz is working on its own? The minimal 'hello world' might be something like import pi3d
disp = pi3d.Display.create(w=200, h=150, window_title="hello world")
for _i in range(1000):
disp.loop_running()
disp.destroy() Which should produce a window with just background. The next step would be rendering a simple shape: import pi3d
disp = pi3d.Display.create(w=200, h=150)
ball = pi3d.Sphere(z=5.0)
for _i in range(1000):
disp.loop_running()
ball.draw()
disp.destroy() And then add keyboard functionality, and after that textures as in pi3d_demos/Minimal.py |
For the first block of code I see Xquartz open in my dock but I don't see any windows open. After roughly 2 seconds I see:
I stuck some print statements in and it appears that the The crash it causes also causes a bunch of my windows to flash black for a second. Most notably the intellij IDE. :) EDIT: Using a debugger I'm unable to get past this call here: pi3d/pi3d/util/DisplayOpenGL.py Lines 98 to 99 in 06057fa
EDIT2: xman and xlogo work fine. Xquartz seems to be working as expected. |
Thanks for soldiering on with this... Hard to figure out problems with the dylib function calls. No debugging or error messages, at best they just don't do anything, at worst stray outside their allocated memory and seg fault! The eglCreateContext caused issues trying to get pi3d running on gentoo64 on the Raspberry Pi, I just couldn't get EGL to provide a context with (SURFACE_TYPE & 4) != 0 you can see what contexts are being offered by running the code below. I would be interested to see what you get. from ctypes import (c_int, byref, Structure, CDLL, POINTER)
from ctypes.util import find_library
egl_name = find_library("EGL")
egl = CDLL(egl_name)
EGL_BUFFER_SIZE = 0x3020
EGL_ALPHA_SIZE = 0x3021
EGL_BLUE_SIZE = 0x3022
EGL_GREEN_SIZE = 0x3023
EGL_RED_SIZE = 0x3024
EGL_DEPTH_SIZE = 0x3025
EGL_STENCIL_SIZE = 0x3026
EGL_SAMPLES = 0x3031
EGL_SURFACE_TYPE = 0x3033
EGL_DEFAULT_DISPLAY = 0
EGLint = c_int
class _EGLDisplay(Structure): ###### EDIT needs this definition to work on gentoo64 is that significant (not needed on laptop 64)
__slots__ = [
]
_EGLDisplay._fields_ = [
('_opaque_struct', EGLint)
]
EGLDisplay = POINTER(_EGLDisplay) #######
class _EGLConfig(Structure):
__slots__ = [
]
_EGLConfig._fields_ = [
('_opaque_struct', EGLint)
]
EGLConfig = POINTER(_EGLConfig)
egl.eglGetDisplay.restype = EGLDisplay ####### EDIT needs this on gentoo64
display = egl.eglGetDisplay(EGL_DEFAULT_DISPLAY)
r = egl.eglInitialize(display, None, None)
attrib_dict = {EGL_RED_SIZE:"RED_SIZE",
EGL_GREEN_SIZE:"GREEN_SIZE",
EGL_BLUE_SIZE:"BLUE_SIZE",
EGL_DEPTH_SIZE:"DEPTH_SIZE",
EGL_ALPHA_SIZE:"ALPHA_SIZE",
EGL_BUFFER_SIZE:"BUFFER_SIZE",
EGL_SAMPLES:"SAMPLES",
EGL_STENCIL_SIZE:"STENCIL_SIZE",
EGL_SURFACE_TYPE:"SURFACE_TYPE"}
numconfig = EGLint(0)
poss_configs = (EGLConfig * 50)(*(EGLConfig() for _ in range(50)))
r = egl.eglGetConfigs(display, byref(poss_configs), EGLint(len(poss_configs)), byref(numconfig))
attr_val = EGLint()
for i in range(numconfig.value):
print(i, "- ", end="")
for attr in attrib_dict:
r = egl.eglGetConfigAttrib(display, poss_configs[i], attr, byref(attr_val))
print("{}={}, ".format(attrib_dict[attr], attr_val.value), end="")
print("") |
Output of that script is:
|
Well most of those look usable so I feel it ought to work. number 11 matches the config asked for so maybe try adding at the end EGL_NO_CONTEXT = 0
context = egl.eglCreateContext(display, poss_configs[11], EGL_NO_CONTEXT, None)
print(context) which differs from DisplayOpenGL.py is that it doesn't try to specify the the client context. It seems to work OK for me here if I pass NULL (represented by None in python) Paddy |
hmm... looks like it is having an issue finding the right library files.
There must be a path that this is using that is separate from |
Not sure why it's looking forOn 30 Jan 2020 18:00, Ryan Jarvis <[email protected]> wrote:hmm... looks like it is having an issue finding the right library files.
0 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=4,
1 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=1,
2 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=5,
3 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=4,
4 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=1,
5 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=5,
6 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=4,
7 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=1,
8 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=4, STENCIL_SIZE=8, SURFACE_TYPE=5,
9 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=0, STENCIL_SIZE=8, SURFACE_TYPE=4,
10 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=0, STENCIL_SIZE=8, SURFACE_TYPE=1,
11 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=0, STENCIL_SIZE=8, SURFACE_TYPE=5,
12 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=0, STENCIL_SIZE=8, SURFACE_TYPE=4,
13 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=0, STENCIL_SIZE=8, SURFACE_TYPE=1,
14 - RED_SIZE=8, GREEN_SIZE=8, BLUE_SIZE=8, DEPTH_SIZE=24, ALPHA_SIZE=8, BUFFER_SIZE=32, SAMPLES=0, STENCIL_SIZE=8, SURFACE_TYPE=5,
(Error) failed to load library 'libGLESv1_CM.dylib'
1
egl_name here is /usr/local/lib/libEGL.dylib.
libGLESv1_CM.dylib is located in /opt/X11/lib which is first in my DYLD_FALLBACK_LIBRARY_PATH
There must be a path that this is using that is separate from DYLD_FALLBACK_LIBRARY_PATH that could help.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
Not sure why it wants that library. Very odd. But it didn't seg fault. You can enter the path in CDLL() explicitly as in the init file.
|
I might need a little handholding there. Where would you like me to put that? |
Sorry! Where the code has egl_name = find_library... You can put ='/usr/local... Or whichever version you want it to use (assuming it's found the wrong one) but not sure why it's looking for GLESv1 at all! |
Maybe I've lost the thread here. The egl_name ( This file ( I believe
I don't have a |
Ryan, yes you're right, you can't tweak where libEGL functions try to load other dynamically loaded libraries apart from by setting system paths. Which seem to be already set up correctly. Or maybe copying files into different directories. Not sure how to get it to load correctly. What happens if you try find_library('GLESv1')? |
$ ls -al /opt/X11/lib/libGLESv*
-rwxr-xr-x 1 root wheel 78672 Oct 29 2016 /opt/X11/lib/libGLESv1_CM.1.dylib
lrwxr-xr-x 1 work wheel 20 Jan 16 11:38 /opt/X11/lib/libGLESv1_CM.dylib -> libGLESv1_CM.1.dylib
-rwxr-xr-x 1 root wheel 128000 Oct 29 2016 /opt/X11/lib/libGLESv2.2.dylib
lrwxr-xr-x 1 work wheel 17 Jan 16 11:38 /opt/X11/lib/libGLESv2.dylib -> libGLESv2.2.dylib |
Well, this discussion is maybe a little bit outdated. I tried to run picframe on my new apple silicon MacBook. I'm using XQuartz as my x11 server (installed through homebrew). I filled the placeholder for _darwin(). def _darwin():
platform = PLATFORM_OSX
bcm = None
opengles = _load_library('/Applications/Google Chrome.app/Contents/Frameworks/Google Chrome Framework.framework/Versions/Current/Libraries/libGLESv2.dylib')
openegl = _load_library('/Applications/Google Chrome.app/Contents/Frameworks/Google Chrome Framework.framework/Versions/Current/Libraries/libEGL.dylib')
return platform, bcm, openegl, opengles # opengles now determined by platform Everything seems to be fine until I receive a segmentation fault at line 325 `DisplayOpenGL.py self.surface = openegl.eglCreateWindowSurface(self.display, self.config, self.window, 0) |
Hi, great that you're trying to get pi3d running on mac, as you can see, despite this being theoretically possible, I've not managed it in the past (in large part because I don't have a mac myself!) I will do a bit more digging but getting a seg fault with that function call makes me think that one or more of the arguments are the wrong type (possibly 32 or 64 bits, I think the new mac has at last abandoned any support for 32 bit applications). |
I tried to use glx. In glx_name = find_library('GLX')
# glx_name = "/opt/homebrew/lib/libxcb-glx.dylib"
glx_name = "/opt/X11/lib/libGL.dylib"
libGLX = CDLL(glx_name) I'm not sure, if I load the correct library. But I get No matching FB config found in else: # work on basis it's X11
# Set some WM info
self.root = xlib.XRootWindowOfScreen(self.screen)
if self.use_glx: # For drawing on X window with transparent background
numfbconfigs = c_int()
VisData = c_ints((
glx.GLX_RENDER_TYPE, glx.GLX_RGBA_BIT,
glx.GLX_DRAWABLE_TYPE, glx.GLX_WINDOW_BIT,
glx.GLX_DOUBLEBUFFER, True,
glx.GLX_RED_SIZE, 8,
glx.GLX_GREEN_SIZE, 8,
glx.GLX_BLUE_SIZE, 8,
glx.GLX_ALPHA_SIZE, 8,
glx.GLX_DEPTH_SIZE, 16,
0))
glx_screen = xlib.XDefaultScreen(self.d)
fbconfigs = glx.glXChooseFBConfig(self.d, glx_screen, VisData, byref(numfbconfigs))
fbconfig = 0
|
I implemented
At the moment I have no idea. Maybe the display or screen? How can I test that? |
OK, seems to work now.
|
@helgeerbe fantastic work getting that running. I'd like to know what it is that makes it work with glx but not egl you had a similar issue getting pi3d running on your linux VM initially. The (non-obvious) glx dependency on egl cropped up before - was that when you were trying to get your linux VM working? |
On my VM (windows host intel based) I enabled 3d hardware acceleration. With that setting egl was not working. Only glx. But on my new Mac with apple silicon (arm). I couldn't find any egl library. I used the library, which comes with chrome. As far as I know mesa supports only glx on Mac for arms. But pi3d is testing if some functions are available in the egl lib. Even if you don't want to use is. I will do some further testing. |
I will fork pi3d and do some cleanup in my code changes. So you can see, what I have done for MacOS on AppleSilicon. What I really don't know, if EGL is available on macOS on intel systems or if there will ever be a port on apple silicon. So I will prepare the code, that on macOS egl is ignored, if now library could be found. |
That would be great. I can't see anywhere in the pi3d code where any functions in Is the the OS on mac not darwin anymore? |
Hi @paddywwoof. I created a #252 pull request. At the end, it were only a couple of code lines, which have to be added. And yes, macOS is still Darwin. |
The text was updated successfully, but these errors were encountered: