On 03/19/2010 01:03 AM, DRC wrote: > I would still try commenting out the _doGLreadback() call. That should > tell you whether the hang is being triggered by VirtualGL calling > glFlush() in the underlying OpenGL subsystem or whether it is triggered > by the glReadPixels() call.
I tried commenting out that call, but it didn't make a difference. Used winedbg to have a look at where it was stalling, first appeared to be in XCopyArea(): Wine-dbg>bt Backtrace: =>0 0x6b726832 GLIBC_2+0x832() in ld-linux.so.2 (0x0033e83c) 1 0x6870ad80 in libxcb.so.1 (+0x7d80) (0x0033e88c) 2 0x6870c9d2 xcb_wait_for_reply+0x142() in libxcb.so.1 (0x0033e92c) 3 0x68430506 _XReply+0xe6() in libx11.so.6 (0x0033e97c) 4 0x68428d81 in libx11.so.6 (+0x39d81) (0x0033e9cc) 5 0x68404b02 XCopyArea+0xb2() in libx11.so.6 (0x0033e9fc) 6 0x68030fb1 XCopyArea+0x1e1() in librrfaker.so (0x0033eedc) 7 0x69e80edf flush_gl_drawable+0xdf(physDev=<register ESI not in topmost frame>) [/home/kvo/wine-git/dlls/winex11.drv/opengl.c:2204] in winex11 (0x0033ef3c) 8 0x69e722b5 X11DRV_ExtEscape+0x525(physDev=<register EDI not in topmost frame>, escape=0x1a85, in_count=0x0004, in_data=<register ESI not in topmost frame>, out_count=0, out_data=0x0(nil)) [/home/kvo/wine-git/dlls/winex11.drv/init.c:434] in winex11 (0x0033f02c) 9 0x6996bd80 ExtEscape+0x50(hdc=0x490, nEscape=0x1a85, cbInput=0x0004, lpszInData=" ", cbOutput=0, lpszOutData=0x0(nil)) [/home/kvo/wine-git/dlls/gdi32/driver.c:717] in gdi32 (0x0033f05c) 10 0x69e831c9 X11DRV_wglFlush+0xa9() [/home/kvo/wine-git/dlls/winex11.drv/opengl.c:2231] in winex11 (0x0033f09c) 11 0x79d4b89c drawPrimitive+0x20c(iface=0x173ee0, index_count=0x0006, StartIdx=0, idxSize=0x0002, idxData=0x4be4950) [/home/kvo/wine-git/dlls/wined3d/drawprim.c:696] in wined3d (0x0033f44c) 12 0x79d1eef1 IWineD3DDeviceImpl_DrawIndexedPrimitive+0xc1(iface=<register ESI not in topmost frame>, startIndex=0, index_count=0x0006) [/home/kvo/wine-git/dlls/wined3d/device.c:4600] in wined3d (0x0033f49c) 13 0x484fb516 IDirect3DDevice9Impl_DrawIndexedPrimitive+0xd6(iface=<register ESI not in topmost frame>, PrimitiveType=<register EDI not in topmost frame>, BaseVertexIndex=0, MinVertexIndex=0, NumVertices=0x0004, startIndex=0, primCount=0x0002) [/home/kvo/wine-git/dlls/d3d9/device.c:1842] in d3d9 (0x0033f4fc) The laptop become responsive again if held execution while in winedbg. So it did seem something was overrunning the X11 queue.. and then got the idea to run a latencytop on the laptop while the issue was manifesting (no idea why I didnt think of that sooner ;P ).. which clearly showed the cause: Cause Maximum Percentage [i915_gem_sw_finish_ioctl] 4181.0 msec 57.5 % [i915_gem_set_domain_ioctl] 3395.2 msec 35.0 % Throttling GPU while waiting for commands 742.0 msec 2.7 % [i915_gem_create_ioctl] 19.7 msec 0.1 % [i915_gem_busy_ioctl] 19.7 msec 0.4 % [i915_gem_pwrite_ioctl] 19.6 msec 0.3 % [i915_gem_madvise_ioctl] 19.6 msec 1.4 % [i915_gem_do_execbuffer] 19.4 msec 0.1 % [i915_do_wait_request] 5.0 msec 0.2 % Cause Maximum Percentage [i915_gem_set_domain_ioctl] 4609.5 msec 32.8 % [i915_gem_sw_finish_ioctl] 3316.7 msec 52.0 % [i915_gem_create_ioctl] 744.1 msec 3.0 % synchronous write 345.9 msec 1.3 % Executing a program 109.7 msec 0.4 % fsync() on a file (type 'F' for details) 87.6 msec 1.0 % Page fault 86.1 msec 0.8 % Writing a page to disk 20.1 msec 0.4 % [i915_gem_madvise_ioctl] 19.7 msec 3.4 % Cause Maximum Percentage [i915_gem_set_domain_ioctl] 3027.2 msec 53.9 % fsync() on a file (type 'F' for details) 72.0 msec 9.1 % Waiting for event (poll) 5.0 msec 13.5 % Waiting for event (select) 4.8 msec 0.8 % Scheduler: waiting for cpu 3.8 msec 3.7 % opening cdrom device 3.7 msec 2.1 % Executing raw SCSI command 3.3 msec 2.2 % Userspace lock contention 2.9 msec 13.0 % [usb_kill_urb] 2.2 msec 0.9 % Hence it looks like a bug in the i915 driver where it is spinning on some lock or something... so time to change mailing lists :-) Thx for the help/ideas nevertheless ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
