Created attachment 140431 [details] xorg.0.log with --enable-debug=full 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) Since 5cc9ed4b9a7ac579362ccebac67f7a4cdb36de06 almost everything is fine, except wine with several programs like sometimes steam, skyrim, mass effect 2 causes this message in the xorg.0.log: (EE) intel(0): Failed to submit rendering commands, disabling acceleration. I have only been able to trigger the error with wine yet. Many complex native games and even all of piglit quick.py runs fine without triggering the error. Here are two different complete xorg.0.log with xf86-video-intel compiled with --enable-debug: http://pastebin.com/raw.php?i=cq21cs1W http://pastebin.com/raw.php?i=cqnQAchm wine is with d3dstream patches, but happens also with CSMT=disabled, a 1920x1080 virtual wine desktop is used xf86-video-intel is git master xorg server 1.15.1 with dri3 patches. mesa is from git master + axeldavy's offloading patches. The games were also run with offloading to a radeon gpu, but the error also happens when everything is run on the intel gpu. It happens always with tearfree enabled and disabled, with sna and with uxa and with dri3 and with --disable-dri3. Here is dmesg with drm.debug=7 http://pastebin.com/raw.php?i=Dxwm0ytg Timestamp reference: [ 66.425] (EE) intel(0): Failed to submit rendering commands, disabling acceleration. sorry for so much pastebin, I'm not too sure what is actually relevant to attach. Attached is xorg.0.log with xf86-video-intel --enable-debug=full, compressed with xz because it's 33 megabyte uncompressed.
commit df89b4941130b5ff020c6ef3e244dcf5fec45f2a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 19 20:39:59 2014 +0100 sna: Mark upload from SHM segment as read-only As this may be mapped by the Xserver using a read-only SHM segment, we are forced to treat it always as read-only. And this being X, that it is using a SHM segment is opaque to the driver. Fantastic middlelayer. This was incorrectly removed in commit e680e54eab6ffa72e5e1eb6cc0e3fe4b235b06a1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 11 10:48:26 2014 +0100 sna: Ignore setting read-only for temporary userptr maps Reported-by: Christoph Haag <haagch.christoph@googlemail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=78411 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 140471 [details] not fixed Sorry, not fixed with this commit. I can still reproduce this immediately with wine. It also happens with uxa. Shall I upload another log with --enable-debug=full?
Strange. That should have been the efault. Please do upload a new trace.
Created attachment 140481 [details] --enable-debug=full with df89b4941130b5ff020c6ef3e244dcf5fec45f2a
Gah. commit 113a8b9be9dd7ffbc6f7c713bc40561bdf38e8b0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 19 20:39:59 2014 +0100 sna: Mark upload from SHM segment as read-only As this may be mapped by the Xserver using a read-only SHM segment, we are forced to treat it always as read-only. And this being X, that it is using a SHM segment is opaque to the driver. Fantastic middlelayer. This was incorrectly removed in commit e680e54eab6ffa72e5e1eb6cc0e3fe4b235b06a1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 11 10:48:26 2014 +0100 sna: Ignore setting read-only for temporary userptr maps Also let's not forget the ShmPutImage -> CopyArea path. Reported-by: Christoph Haag <haagch.christoph@googlemail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=78411 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After a quick test it seems like it is fixed. Thanks!