Driver hangs in ioctl


I’m debugging a system with a 1.7 driver that copies data between large 3D fbo textures using glBiltFramebuffers. One of these calls hangs in a function called ioctl forever:

#0 ioctl () at …/sysdeps/unix/sysv/linux/aarch64/ioctl.S:26
#1 0x0000007f8582fb54 in drmIoctl (fd=0xc9, request=0xc0206440, arg=0x7f1c429ad8)
at /home/jenkins-slave/workspace/release_system__ext-libdrm/work/system/ext-libdrm/src/1/workspace/libdrm-2.4.68/xf86drm.c:172
#2 0x0000007f877292a4 in PVRSRVBridgeCall (hServices=0x7ecc05fb10, ui8BridgeGroup=0x1, ui32FunctionID=0x6,
pvParamIn=0x7f1c429b38, ui32InBufferSize=0x8, pvParamOut=0x7f1c429b30, ui32OutBufferSize=0x4)
at services/client/env/linux/common/pvr_bridge_u.c:648
#3 0x0000007f87722688 in BridgeEventObjectWait (hBridge=0x7ecc05fb10, hOSEventKM=0x4a)
at generated/srvcore_bridge/client_srvcore_bridge.c:385
#4 0x0000007f876f5c00 in PVRSRVEventObjectWait (psConnection=0x7ecc056ea0, hEvent=0x4a)
at services/client/common/srvcore.c:453
#5 0x0000007f8b146544 in WaitForRender (gc=0x7ecc0a2dc0, psSurface=0x7ecc8acf30) at opengles3/rgxif.c:179
#6 0x0000007f8b14c914 in ScheduleTA (gc=0x7ecc0a2dc0, psRenderSurface=0x7ecc8acf30, ui32KickFlags=0x5,
KickReason=REASON_FLUSHRENDERSURFACE) at opengles3/rgxif.c:5084
#7 0x0000007f8b1118bc in FlushRenderSurface (gc=0x7ecc0a2dc0, psRenderSurface=0x7ecc8acf30, ui32KickFlags=0x5)
at opengles3/fbo.c:824
#8 0x0000007f8b111d2c in DestroyFBORenderSurface (gc=0x7ecc0a2dc0, psFrameBuffer=0x7ecc665230, bNeedsFlush=IMG_TRUE)
at opengles3/fbo.c:1029
#9 0x0000007f8b1164a4 in ComputeFrameBufferCompleteness (gc=0x7ecc0a2dc0, psFrameBuffer=0x7ecc665230)
at opengles3/fbo.c:3986
#10 0x0000007f8b117124 in GetFrameBufferCompleteness (gc=0x7ecc0a2dc0, psFrameBuffer=0x7ecc665230)
at opengles3/fbo.c:4391
#11 0x0000007f8b0ed6f8 in glBlitFramebuffer (srcX0=0x0, srcY0=0x0, srcX1=0x100, srcY1=0x100, dstX0=0x0, dstY0=0x0,
dstX1=0x100, dstY1=0x100, mask=mask@entry=0x4000, filter=filter@entry=0x2601) at opengles3/blit.c:1683

What it is doing is copying the contents of a 512x512x64 fbo to a different fbo of the same size which is allocated shortly before glBiltFramebuffers.

Is this behaviour normal?



this is probably a driver bug, what platform are you using? what is the exact version of the driver?
can you please describe your fbo usage exactly? might be able to suggest a workaround.


Driver version 1.9, ARM Linux.

It is used in a conjunction with a 2d texture array that simulates a texture stack.

Can you please tell me the GL_VERSION string?