Deadlocks when accessing Context with active GL interop #235
Comments
|
here we go: from OpenGL.GL import *
from OpenGL.GLUT import *
import pyopencl as cl
import pyopencl.array
import numpy as np
def get_ctx():
from pyopencl.tools import get_gl_sharing_context_properties
import sys
platform = cl.get_platforms()[0]
if sys.platform == "darwin":
return cl.Context(properties=get_gl_sharing_context_properties(),
devices=[])
else:
# Some OSs prefer clCreateContextFromType, some prefer
# clCreateContext. Try both.
try:
return cl.Context(properties=[
(cl.context_properties.PLATFORM, platform)]
+ get_gl_sharing_context_properties())
except:
return cl.Context(properties=[
(cl.context_properties.PLATFORM, platform)]
+ get_gl_sharing_context_properties(),
devices = [platform.get_devices()[0]])
glutInit()
def gl_allocator(size):
ubo = glGenBuffers(1)
glBindBuffer(GL_UNIFORM_BUFFER, ubo)
glBufferStorage(GL_UNIFORM_BUFFER, size, None, GL_MAP_READ_BIT | GL_MAP_WRITE_BIT)
glBindBuffer(GL_UNIFORM_BUFFER, 0)
return cl.GLBuffer(ctx, cl.mem_flags.READ_WRITE, int(ubo))
glutInit()
glutInitWindowSize(512, 512)
glutCreateWindow('gpWFC')
glutDisplayFunc(lambda: 0)
ctx = get_ctx()
data = np.arange(100)
with cl.CommandQueue(ctx) as queue:
arr = cl.array.Array(queue, data.shape, data.dtype, allocator=gl_allocator)
def key(*args):
print("key pressed")
with cl.CommandQueue(ctx) as queue:
cl.enqueue_acquire_gl_objects(queue, [arr.base_data])
queue.context
arr.set(data, queue=queue)
cl.enqueue_release_gl_objects(queue, [arr.base_data])
glutKeyboardFunc(key)
glutMainLoop()let this open, press any key once and it should lock up. |
I'd discourage in-place modification of
That's weird. OpenCL is reference counted, so all |
|
@inducer I tried that but it also triggered the hang. Maybe If you don't have time to look into this, could you recommend a debugging strategy? EDIT: leaving this link here for reference, I'll check my dmesg output next time and also see if I can get a test setup on Windows. |
s-ol
changed the title
|
I have not, sorry. But you may want to retry with git master, which is a whole different code base (actually, mostly a revival of the old Boost.Python code on top of pybind11). |
Great, I've given it a shot but I am experiencing some issues with NVIDIA Optimus / Bumblebee on my laptop: Bumblebee-Project/Bumblebee#778 Having dealt with these things in the past though, I think the fix is just waiting until I get back to my desktop PC where optimus doesn't get in the way. |
|
Unfortunately still experiencing the same problem: This is my own code, but interestingly enough I now have the same problem running However |
|
What are the differences in the context setup code between |
|
in while in replacing the second with the first doesn't change the outcome though: Also I finally managed to load the python GDB utils but it doesn't give any more information (because my python version is not compiled for debugging I assume): |
|
So the fact that the backtrace contains |
I'm having trouble porting my array-based code to an interop-based renderer.
I'm instantating the array like this:
using an allocator:
to_devicecannot work because it doesn'tacquiretheGLBuffer, and I cannot do that beforehand since the buffer isn't allocated yet.It works like this:
for some reason passing a
Contextinstead of aCommandQueuemakes this lock up here. Freeing the context seems like the wrong thing to do...?The same deadlock is preventing me from using
grid.with_queue(),grid.setitem()etc.I realized later that I can trigger it just by accessing the
contextattribute of aCommandQueue:interestingly it runs until 'got here' but I never see the result of the
setcall. Thestep()method also never returns for me.If I debug the script in
pudb, the interface closes as I step out of the method.I'll see if i can create a small reproducable example now.
The text was updated successfully, but these errors were encountered: