[Mesa-dev] Alternative to DRM_IOCTL_GEM_OPEN for render-nodes
Tom Stellard
tom at stellard.net
Tue Apr 15 14:03:44 PDT 2014
Hi,
I've been trying to get piglit working on radeon without X using gbm and
render-nodes, and the problem right now is that the radeon winsys is
trying to use DRM_IOCTL_GEM_OPEN, which is not allowed with render-nodes.
I'm not sure if we need to replace this ioctl with something else or
if the problem is in the gallium DRI2 implementation and we really shouldn't
be hitting this code path. Here is a stack trace:
#0 radeon_winsys_bo_from_handle (rws=0x60f450, whandle=0x7fffffffd510,
stride=0x7fffffffd4a0)
at radeon_drm_bo.c:909
#1 0x00007ffff64ef0ed in r600_texture_from_handle (screen=0x60fdf0,
templ=0x7fffffffd520,
whandle=0x7fffffffd510) at r600_texture.c:801
#2 0x00007ffff64fed13 in dri2_drawable_process_buffers (ctx=0x6379b0,
drawable=0x67cb50, buffers=0x67c9d0,
buffer_count=1, atts=0x67d190, att_count=1) at dri2.c:313
#3 0x00007ffff64ff456 in dri2_allocate_textures (ctx=0x6379b0,
drawable=0x67cb50, statts=0x67d190,
statts_count=1) at dri2.c:515
#4 0x00007ffff64fd56f in dri_st_framebuffer_validate (stctx=0x674e50,
stfbi=0x67cb50, statts=0x67d190,
count=1, out=0x7fffffffd6d0) at dri_drawable.c:83
#5 0x00007ffff61fc44c in st_framebuffer_validate (stfb=0x67cd40,
st=0x674e50) at state_tracker/st_manager.c:193
#6 0x00007ffff61fd5fb in st_api_make_current (stapi=0x7ffff68e77c0
<st_gl_api>, stctxi=0x674e50,
stdrawi=0x67cb50, streadi=0x67cb50) at
state_tracker/st_manager.c:763
#7 0x00007ffff64fc33b in dri_make_current (cPriv=0x637f70,
driDrawPriv=0x67cb10, driReadPriv=0x67cb10)
at dri_context.c:253
#8 0x00007ffff6017917 in driBindContext (pcp=0x637f70, pdp=0x67cb10,
prp=0x67cb10) at dri_util.c:543
#9 0x00007ffff75e32e0 in dri2_make_current (drv=0x637480,
disp=0x632f50, dsurf=0x67c950, rsurf=0x67c950,
ctx=0x637fb0) at egl_dri2.c:988
#10 0x00007ffff75d64d4 in eglMakeCurrent (dpy=0x632f50, draw=0x67c950,
read=0x67c950, ctx=0x637fb0)
at eglapi.c:538
Does anyone have any ideas what to do here?
Thanks,
Tom
More information about the mesa-dev
mailing list