Bug 89058

Created attachment 113299 [details]
Xorg.0.log info

Created attachment 113300 [details]
etqw-demo picture

Created attachment 113301 [details]
nexuiz picture

Created attachment 113302 [details]
portal picture

Created attachment 113303 [details]
doom3 picture

Render error when I manually run doom3 game.

Render error when I manually run Steam CS game.

Comment on attachment 113299 [details]
Xorg.0.log info

>[    33.778] 
>X.Org X Server 1.17.0
>Release Date: 2015-02-02
>[    33.778] X Protocol Version 11, Revision 0
>[    33.778] Build Operating System: Linux 3.18.0+ x86_64 
>[    33.778] Current Operating System: Linux x-skly06 3.19.0-rc7_drm-intel-nightly_b4442e_20150208+ #198 SMP Sun Feb 8 11:22:38 CST 2015 x86_64
>[    33.778] Kernel command line: BOOT_IMAGE=/boot/bzImage_x86_64 root=UUID=f53c75c6-eeb6-4aa4-98a8-51aeb7219d2a ro hpet=disable i915.debug=0xe
>[    33.778] Build Date: 08 February 2015  03:26:52PM
>[    33.778]  
>[    33.778] Current version of pixman: 0.33.1
>[    33.778] 	Before reporting problems, check http://wiki.x.org
>	to make sure that you have the latest version.
>[    33.778] Markers: (--) probed, (**) from config file, (==) default setting,
>	(++) from command line, (!!) notice, (II) informational,
>	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>[    33.779] (==) Log file: "/opt/X11R7/var/log/Xorg.0.log", Time: Tue Feb 10 07:18:50 2015
>[    33.780] (==) Using config file: "/etc/X11/xorg.conf"
>[    33.780] (==) Using system config directory "/opt/X11R7/share/X11/xorg.conf.d"
>[    33.781] (==) ServerLayout "X.org Configured"
>[    33.781] (**) |-->Screen "Screen0" (0)
>[    33.781] (**) |   |-->Monitor "Monitor0"
>[    33.781] (**) |   |-->Device "Card0"
>[    33.782] (**) |-->Input Device "Mouse0"
>[    33.782] (**) |-->Input Device "Keyboard0"
>[    33.782] (==) Automatically adding devices
>[    33.782] (==) Automatically enabling devices
>[    33.782] (==) Automatically adding GPU devices
>[    33.782] (WW) The directory "/opt/X11R7/share/fonts/X11/misc/" does not exist.
>[    33.782] 	Entry deleted from font path.
>[    33.782] (WW) The directory "/opt/X11R7/share/fonts/X11/TTF/" does not exist.
>[    33.782] 	Entry deleted from font path.
>[    33.782] (WW) The directory "/opt/X11R7/share/fonts/X11/OTF/" does not exist.
>[    33.782] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/100dpi/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/75dpi/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/misc/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/TTF/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/OTF/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/100dpi/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (WW) The directory "/opt/X11R7/share/fonts/X11/75dpi/" does not exist.
>[    33.783] 	Entry deleted from font path.
>[    33.783] (**) FontPath set to:
>	/opt/X11R7/share/fonts/X11/Type1/,
>	/opt/X11R7/share/fonts/X11/Type1/
>[    33.783] (**) ModulePath set to "/opt/X11R7/lib/xorg/modules"
>[    33.783] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
>[    33.783] (WW) Disabling Mouse0
>[    33.783] (WW) Disabling Keyboard0
>[    33.783] (II) Loader magic: 0x807cc0
>[    33.783] (II) Module ABI versions:
>[    33.783] 	X.Org ANSI C Emulation: 0.4
>[    33.783] 	X.Org Video Driver: 19.0
>[    33.783] 	X.Org XInput driver : 21.0
>[    33.783] 	X.Org Server Extension : 9.0
>[    33.785] (EE) systemd-logind: TakeControl failed: Method "TakeControl" with signature "b" on interface "org.freedesktop.login1.Session" doesn't exist
>
>[    33.785] (II) xfree86: Adding drm device (/dev/dri/card0)
>[    33.792] (--) PCI:*(0:0:2:0) 8086:191e:8086:2212 rev 2, Mem @ 0xc0000000/16777216, 0xb0000000/268435456, I/O @ 0x00004000/64
>[    33.792] (II) Open ACPI successful (/var/run/acpid.socket)
>[    33.792] (II) "glx" will be loaded. This was enabled by default and also specified in the config file.
>[    33.792] (II) LoadModule: "record"
>[    33.792] (II) Module "record" already built-in
>[    33.792] (II) LoadModule: "extmod"
>[    33.792] (II) Module "extmod" already built-in
>[    33.792] (II) LoadModule: "dbe"
>[    33.792] (II) Module "dbe" already built-in
>[    33.792] (II) LoadModule: "dri2"
>[    33.792] (II) Module "dri2" already built-in
>[    33.792] (II) LoadModule: "glx"
>[    33.793] (II) Loading /opt/X11R7/lib/xorg/modules/extensions/libglx.so
>[    33.838] (II) Module glx: vendor="X.Org Foundation"
>[    33.839] 	compiled for 1.17.0, module version = 1.0.0
>[    33.839] 	ABI class: X.Org Server Extension, version 9.0
>[    33.839] (==) AIGLX enabled
>[    33.839] (II) LoadModule: "dri"
>[    33.839] (II) Module "dri" already built-in
>[    33.839] (II) LoadModule: "intel"
>[    33.839] (II) Loading /opt/X11R7/lib/xorg/modules/drivers/intel_drv.so
>[    33.842] (II) Module intel: vendor="X.Org Foundation"
>[    33.842] 	compiled for 1.17.0, module version = 2.99.917
>[    33.842] 	Module class: X.Org Video Driver
>[    33.842] 	ABI class: X.Org Video Driver, version 19.0
>[    33.842] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
>	i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
>	915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
>	Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
>	GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
>[    33.842] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
>[    33.842] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
>[    33.842] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300
>[    33.842] (--) using VT number 8
>
>[    33.893] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20150130
>[    33.893] (II) intel(0): SNA compiled from 2.99.917-94-g26ba2ba
>[    33.895] (--) intel(0): gen9 engineering sample
>[    33.895] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2; using a maximum of 2 threads
>[    33.895] (==) intel(0): Depth 24, (--) framebuffer bpp 32
>[    33.895] (==) intel(0): RGB weight 888
>[    33.895] (==) intel(0): Default visual is TrueColor
>[    33.895] (II) intel(0): Output eDP1 using monitor section Monitor0
>[    33.896] (--) intel(0): Found backlight control interface intel_backlight (type 'raw') for output eDP1
>[    33.896] (II) intel(0): Enabled output eDP1
>[    33.896] (II) intel(0): Output DP1 has no monitor section
>[    33.896] (II) intel(0): Enabled output DP1
>[    33.896] (II) intel(0): Output HDMI1 has no monitor section
>[    33.896] (II) intel(0): Enabled output HDMI1
>[    33.896] (II) intel(0): Output DP2 has no monitor section
>[    33.896] (II) intel(0): Enabled output DP2
>[    33.896] (II) intel(0): Output HDMI2 has no monitor section
>[    33.896] (II) intel(0): Enabled output HDMI2
>[    33.896] (--) intel(0): Using a maximum size of 256x256 for hardware cursors
>[    33.896] (II) intel(0): Output VIRTUAL1 has no monitor section
>[    33.896] (II) intel(0): Enabled output VIRTUAL1
>[    33.896] (--) intel(0): Output eDP1 using initial mode 3200x1800 on pipe 0
>[    33.896] (==) intel(0): TearFree disabled
>[    33.896] (==) intel(0): DPI set to (96, 96)
>[    33.896] (II) Loading sub module "dri2"
>[    33.896] (II) LoadModule: "dri2"
>[    33.896] (II) Module "dri2" already built-in
>[    33.896] (II) Loading sub module "present"
>[    33.896] (II) LoadModule: "present"
>[    33.896] (II) Module "present" already built-in
>[    33.896] (==) Depth 24 pixmap format is 32 bpp
>[    33.898] (II) intel(0): SNA initialized with generic backend
>[    33.898] (==) intel(0): Backing store enabled
>[    33.898] (==) intel(0): Silken mouse enabled
>[    33.898] (II) intel(0): HW Cursor enabled
>[    33.898] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
>[    33.899] (==) intel(0): DPMS enabled
>[    33.899] (==) intel(0): Display hotplug detection enabled
>[    33.899] (II) intel(0): Textured video not supported on this hardware or backend
>[    33.899] (II) intel(0): [DRI2] Setup complete
>[    33.899] (II) intel(0): [DRI2]   DRI driver: i965
>[    33.899] (II) intel(0): [DRI2]   VDPAU driver: va_gl
>[    33.899] (II) intel(0): direct rendering: DRI2 enabled
>[    33.899] (II) intel(0): hardware support for Present enabled
>[    33.899] (--) RandR disabled
>[    33.961] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
>[    33.961] (II) AIGLX: enabled GLX_ARB_create_context
>[    33.961] (II) AIGLX: enabled GLX_ARB_create_context_profile
>[    33.961] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile
>[    33.961] (II) AIGLX: enabled GLX_INTEL_swap_event
>[    33.961] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
>[    33.961] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
>[    33.961] (II) AIGLX: enabled GLX_ARB_fbconfig_float
>[    33.961] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
>[    33.961] (II) AIGLX: enabled GLX_ARB_create_context_robustness
>[    33.961] (II) AIGLX: Loaded and initialized i965
>[    33.961] (II) GLX: Initialized DRI2 GL provider for screen 0
>[    33.973] (II) intel(0): switch to mode 3200x1800@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
>[    33.973] (II) intel(0): Setting screen physical size to 846 x 476
>[    34.056] (II) config/udev: Adding input device Power Button (/dev/input/event4)
>[    34.056] (**) Power Button: Applying InputClass "evdev keyboard catchall"
>[    34.056] (II) LoadModule: "evdev"
>[    34.056] (II) Loading /opt/X11R7/lib/xorg/modules/input/evdev_drv.so
>[    34.090] (II) Module evdev: vendor="X.Org Foundation"
>[    34.090] 	compiled for 1.17.0, module version = 2.9.1
>[    34.090] 	Module class: X.Org XInput Driver
>[    34.090] 	ABI class: X.Org XInput driver, version 21.0
>[    34.090] (II) Using input driver 'evdev' for 'Power Button'
>[    34.090] (**) Power Button: always reports core events
>[    34.090] (**) evdev: Power Button: Device: "/dev/input/event4"
>[    34.090] (--) evdev: Power Button: Vendor 0 Product 0x1
>[    34.090] (--) evdev: Power Button: Found keys
>[    34.090] (II) evdev: Power Button: Configuring as keyboard
>[    34.090] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event4"
>[    34.090] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6)
>[    34.090] (**) Option "xkb_rules" "evdev"
>[    34.090] (**) Option "xkb_model" "pc105"
>[    34.090] (**) Option "xkb_layout" "us"
>[    34.091] (II) config/udev: Adding input device Video Bus (/dev/input/event5)
>[    34.091] (**) Video Bus: Applying InputClass "evdev keyboard catchall"
>[    34.091] (II) Using input driver 'evdev' for 'Video Bus'
>[    34.091] (**) Video Bus: always reports core events
>[    34.091] (**) evdev: Video Bus: Device: "/dev/input/event5"
>[    34.091] (--) evdev: Video Bus: Vendor 0 Product 0x6
>[    34.091] (--) evdev: Video Bus: Found keys
>[    34.091] (II) evdev: Video Bus: Configuring as keyboard
>[    34.091] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7/event5"
>[    34.091] (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD, id 7)
>[    34.091] (**) Option "xkb_rules" "evdev"
>[    34.091] (**) Option "xkb_model" "pc105"
>[    34.091] (**) Option "xkb_layout" "us"
>[    34.092] (II) config/udev: Adding input device Lid Switch (/dev/input/event1)
>[    34.092] (II) No input driver specified, ignoring this device.
>[    34.092] (II) This device may have been added with another device file.
>[    34.092] (II) config/udev: Adding input device Power Button (/dev/input/event2)
>[    34.092] (**) Power Button: Applying InputClass "evdev keyboard catchall"
>[    34.092] (II) Using input driver 'evdev' for 'Power Button'
>[    34.092] (**) Power Button: always reports core events
>[    34.092] (**) evdev: Power Button: Device: "/dev/input/event2"
>[    34.093] (--) evdev: Power Button: Vendor 0 Product 0x1
>[    34.093] (--) evdev: Power Button: Found keys
>[    34.093] (II) evdev: Power Button: Configuring as keyboard
>[    34.093] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input4/event2"
>[    34.093] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 8)
>[    34.093] (**) Option "xkb_rules" "evdev"
>[    34.093] (**) Option "xkb_model" "pc105"
>[    34.093] (**) Option "xkb_layout" "us"
>[    34.093] (II) config/udev: Adding input device Sleep Button (/dev/input/event3)
>[    34.093] (**) Sleep Button: Applying InputClass "evdev keyboard catchall"
>[    34.093] (II) Using input driver 'evdev' for 'Sleep Button'
>[    34.093] (**) Sleep Button: always reports core events
>[    34.093] (**) evdev: Sleep Button: Device: "/dev/input/event3"
>[    34.093] (--) evdev: Sleep Button: Vendor 0 Product 0x3
>[    34.093] (--) evdev: Sleep Button: Found keys
>[    34.093] (II) evdev: Sleep Button: Configuring as keyboard
>[    34.093] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input5/event3"
>[    34.093] (II) XINPUT: Adding extended input device "Sleep Button" (type: KEYBOARD, id 9)
>[    34.093] (**) Option "xkb_rules" "evdev"
>[    34.093] (**) Option "xkb_model" "pc105"
>[    34.093] (**) Option "xkb_layout" "us"
>[    34.094] (II) config/udev: Adding input device Logitech USB Optical Mouse (/dev/input/event7)
>[    34.094] (**) Logitech USB Optical Mouse: Applying InputClass "evdev pointer catchall"
>[    34.094] (II) Using input driver 'evdev' for 'Logitech USB Optical Mouse'
>[    34.095] (**) Logitech USB Optical Mouse: always reports core events
>[    34.095] (**) evdev: Logitech USB Optical Mouse: Device: "/dev/input/event7"
>[    34.146] (--) evdev: Logitech USB Optical Mouse: Vendor 0x46d Product 0xc077
>[    34.146] (--) evdev: Logitech USB Optical Mouse: Found 12 mouse buttons
>[    34.146] (--) evdev: Logitech USB Optical Mouse: Found scroll wheel(s)
>[    34.146] (--) evdev: Logitech USB Optical Mouse: Found relative axes
>[    34.146] (--) evdev: Logitech USB Optical Mouse: Found x and y relative axes
>[    34.146] (II) evdev: Logitech USB Optical Mouse: Configuring as mouse
>[    34.146] (II) evdev: Logitech USB Optical Mouse: Adding scrollwheel support
>[    34.146] (**) evdev: Logitech USB Optical Mouse: YAxisMapping: buttons 4 and 5
>[    34.146] (**) evdev: Logitech USB Optical Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
>[    34.146] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1:1.0/0003:046D:C077.0001/input/input8/event7"
>[    34.146] (II) XINPUT: Adding extended input device "Logitech USB Optical Mouse" (type: MOUSE, id 10)
>[    34.146] (II) evdev: Logitech USB Optical Mouse: initialized for relative axes.
>[    34.146] (**) Logitech USB Optical Mouse: (accel) keeping acceleration scheme 1
>[    34.146] (**) Logitech USB Optical Mouse: (accel) acceleration profile 0
>[    34.146] (**) Logitech USB Optical Mouse: (accel) acceleration factor: 2.000
>[    34.146] (**) Logitech USB Optical Mouse: (accel) acceleration threshold: 4
>[    34.147] (II) config/udev: Adding input device Logitech USB Optical Mouse (/dev/input/mouse1)
>[    34.147] (II) No input driver specified, ignoring this device.
>[    34.147] (II) This device may have been added with another device file.
>[    34.148] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event0)
>[    34.148] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
>[    34.148] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
>[    34.148] (**) AT Translated Set 2 keyboard: always reports core events
>[    34.148] (**) evdev: AT Translated Set 2 keyboard: Device: "/dev/input/event0"
>[    34.148] (--) evdev: AT Translated Set 2 keyboard: Vendor 0x1 Product 0x1
>[    34.148] (--) evdev: AT Translated Set 2 keyboard: Found keys
>[    34.148] (II) evdev: AT Translated Set 2 keyboard: Configuring as keyboard
>[    34.148] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input0/event0"
>[    34.148] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 11)
>[    34.148] (**) Option "xkb_rules" "evdev"
>[    34.148] (**) Option "xkb_model" "pc105"
>[    34.148] (**) Option "xkb_layout" "us"
>[    34.148] (II) config/udev: Adding input device ImPS/2 Logitech Wheel Mouse (/dev/input/event6)
>[    34.149] (**) ImPS/2 Logitech Wheel Mouse: Applying InputClass "evdev pointer catchall"
>[    34.149] (II) Using input driver 'evdev' for 'ImPS/2 Logitech Wheel Mouse'
>[    34.149] (**) ImPS/2 Logitech Wheel Mouse: always reports core events
>[    34.149] (**) evdev: ImPS/2 Logitech Wheel Mouse: Device: "/dev/input/event6"
>[    34.149] (--) evdev: ImPS/2 Logitech Wheel Mouse: Vendor 0x2 Product 0x5
>[    34.149] (--) evdev: ImPS/2 Logitech Wheel Mouse: Found 3 mouse buttons
>[    34.149] (--) evdev: ImPS/2 Logitech Wheel Mouse: Found scroll wheel(s)
>[    34.149] (--) evdev: ImPS/2 Logitech Wheel Mouse: Found relative axes
>[    34.149] (--) evdev: ImPS/2 Logitech Wheel Mouse: Found x and y relative axes
>[    34.149] (II) evdev: ImPS/2 Logitech Wheel Mouse: Configuring as mouse
>[    34.149] (II) evdev: ImPS/2 Logitech Wheel Mouse: Adding scrollwheel support
>[    34.149] (**) evdev: ImPS/2 Logitech Wheel Mouse: YAxisMapping: buttons 4 and 5
>[    34.149] (**) evdev: ImPS/2 Logitech Wheel Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
>[    34.149] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio1/input/input2/event6"
>[    34.149] (II) XINPUT: Adding extended input device "ImPS/2 Logitech Wheel Mouse" (type: MOUSE, id 12)
>[    34.149] (II) evdev: ImPS/2 Logitech Wheel Mouse: initialized for relative axes.
>[    34.149] (**) ImPS/2 Logitech Wheel Mouse: (accel) keeping acceleration scheme 1
>[    34.149] (**) ImPS/2 Logitech Wheel Mouse: (accel) acceleration profile 0
>[    34.149] (**) ImPS/2 Logitech Wheel Mouse: (accel) acceleration factor: 2.000
>[    34.149] (**) ImPS/2 Logitech Wheel Mouse: (accel) acceleration threshold: 4
>[    34.149] (II) config/udev: Adding input device ImPS/2 Logitech Wheel Mouse (/dev/input/mouse0)
>[    34.150] (II) No input driver specified, ignoring this device.
>[    34.150] (II) This device may have been added with another device file.
>[    34.150] (II) config/udev: Adding input device PC Speaker (/dev/input/event8)
>[    34.150] (II) No input driver specified, ignoring this device.
>[    34.150] (II) This device may have been added with another device file.
>[    38.514] (II) intel(0): EDID vendor "SDC", prod id 16970
>[    38.514] (II) intel(0): Printing DDC gathered Modelines:
>[    38.514] (II) intel(0): Modeline "3200x1800"x0.0  361.31  3200 3248 3280 3316  1800 1802 1807 1816 -hsync -vsync (109.0 kHz eP)
>[    38.514] (II) intel(0): Modeline "3200x1800"x0.0  361.31  3200 3248 3280 3680  1800 1802 1807 2045 -hsync -vsync (98.2 kHz e)

Created attachment 113307 [details]
Xorg.0.log info

This bug is also exist by Mesa10.5rc2 testing

Created attachment 113882 [details]
Render error during run xonotic manual test

I tried running Xonotic and I can replicate the broken screenshot with git master of Mesa (currently 6ac1bc9). I have some Skylake fixes which have not yet been pushed to master and if I run it with those then it seems to fix the problem. Bisecting it seems to point to this patch:

http://lists.freedesktop.org/archives/mesa-dev/2015-March/078569.html

The patches might fix some of the other games too, but I haven't tried it. If anyone wants to try the patches, they are available in this git repo:

https://github.com/bpeel/mesa/tree/wip/skylake

You also need this patch for libdrm:

http://lists.freedesktop.org/archives/dri-devel/2015-March/078741.html

Neil, you need to mark it as "NEEDINFO" if you want QA to see it...

(In reply to Neil Roberts from comment #12)
> I tried running Xonotic and I can replicate the broken screenshot with git
> master of Mesa (currently 6ac1bc9). I have some Skylake fixes which have not
> yet been pushed to master and if I run it with those then it seems to fix
> the problem. Bisecting it seems to point to this patch:
> 
> http://lists.freedesktop.org/archives/mesa-dev/2015-March/078569.html
> 
> The patches might fix some of the other games too, but I haven't tried it.
> If anyone wants to try the patches, they are available in this git repo:
> 
> https://github.com/bpeel/mesa/tree/wip/skylake
> 
> You also need this patch for libdrm:
> 
> http://lists.freedesktop.org/archives/dri-devel/2015-March/078741.html


Tested with Mesa(07856) and libdrm(078741)patch. Xonotic still render error.

(In reply to ye.tian from comment #14)

This seems a bit surprising. I can replicate the screenshot with git master (627c68308683ab) and if I apply the patches then it is fixed. I should have mentioned that if you want to apply the patches from the mailing list it won't compile without two other patches so you would need all three of these:

http://lists.freedesktop.org/archives/mesa-dev/2015-March/078534.html
http://lists.freedesktop.org/archives/mesa-dev/2015-March/078570.html
http://lists.freedesktop.org/archives/mesa-dev/2015-March/078569.html

And also of course the libdrm patch:

http://lists.freedesktop.org/archives/dri-devel/2015-March/078741.html

Did you test with all of these patches?

Thanks

(In reply to Neil Roberts from comment #15)

Tested with all of these patches on the latest masa(2372275, Xonotic can render normal, but the other games(etqw,portal) still render error.

According to Anuj in bug 89039 a rendering error in etqw-demo was fixed in this patch:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=5a06ee7384934f8b5177

That patch is now in Git master (5a06ee7384) so it may be worth trying again with that.

The screenshot from etqw looks more like a problem with the vertices getting the wrong position. In that case it makes sense that that patch would help with the problem because as far as I can tell the Doom III engine which etqw is based on uses ARBvp programs which would cause a SIMD4x2 vertex program to be generated.

I think this patch is tracking several independent bugs.

Tested etqw-demo on master (5a06ee7384), etwq-demo still render error.
please see the picture.

Tested etwq-demo on the latest master(27bf37ba), etwq-demo still render error.
please see the picture.

This two commit rendering error pictures are not the same.

Created attachment 114458 [details]
commit (5a06ee7)

Created attachment 114459 [details]
commit (27bf37b)

Created attachment 114460 [details]
commit (27bf37b)

I think I have isolated the ARBvp program that is being used to render a part of the gun that's getting corrupted. I can send it if someone requests it.

An unusual thing I can see with the compiled program is that it ends up doing a send instruction with the same src and dst register. The send instruction is to do a constant load. At a glance I can't find anything to say whether it's acceptable to do a send with overlapping src and dst so I don't know whether that's really a problem. However if I enable the trivial allocator it no longer does this and the rendering error is fixed.

I don't know the register allocator well enough to know whether it would normally try to avoid allocating the src and dst registers to the same number. The constant load gets the message header added via my patch in commit 5a06ee7384934f8 so it might be that I've done something to mess it up.

(In reply to Neil Roberts from comment #22)
> I think I have isolated the ARBvp program that is being used to render a
> part of the gun that's getting corrupted. I can send it if someone requests
> it.
> 
> An unusual thing I can see with the compiled program is that it ends up
> doing a send instruction with the same src and dst register. The send
> instruction is to do a constant load. At a glance I can't find anything to
> say whether it's acceptable to do a send with overlapping src and dst so I
> don't know whether that's really a problem. However if I enable the trivial
> allocator it no longer does this and the rendering error is fixed.
> 
> I don't know the register allocator well enough to know whether it would
> normally try to avoid allocating the src and dst registers to the same
> number. The constant load gets the message header added via my patch in
> commit 5a06ee7384934f8 so it might be that I've done something to mess it up.

Yes, IIRC there's a restriction on some newer platforms that send's source and dest cannot overlap. Let me see if I can find that text in the bspec again.

(In reply to Matt Turner from comment #23)
> Yes, IIRC there's a restriction on some newer platforms that send's source
> and dest cannot overlap. Let me see if I can find that text in the bspec
> again.

Hm, maybe not. On the "Register Region Restrictions" page it says for BDW+:

> The src, dst overlapping behavior with the second half src and the first half destination to the same register must not be used with any compressed instruction.

I'm not sure if that's related or not.

Created attachment 114491 [details] [review]
WIP patch

After digging around in the code a bit I'm pretty sure it doesn't normally try to prevent the src and dest being the same for send instructions. I tried experimenting to force Mesa to allocate the same src and dst for an FS texture sample in a simple test on Haswell and it also seems to break so now I'm wondering whether it's a general restriction on many platforms and it's just coincidence that we haven't hit it yet.

This patch seems to fix the rendering error for me but it's not a complete patch because of the reasons described in the commit message.

Ok, I think the thing about the src and dst registers overlapping is a red herring. I can replicate the bug on Haswell by modifying commit 5a06ee7384934f to apply on Gen7, but without setting the SIMD4x2 bit in the header. It also has the bug if I leave it so that allocates register space for the header but doesn't actually send the header which means the registers are no longer overlapping. It seems like it's just the compiler going wrong somehow but if I compare the working one and the non-working one so far I haven't seen anything that looks wrong.

I think I have a better understanding of what's going on. The original ARBvp program has three constant array loads with a non-constant index like this:

MOV		_R0, _joints[_A0.x+0];
MOV		_R1, _joints[_A0.x+1];
MOV		_R2, _joints[_A0.x+2];

These get converted to VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 instructions which is something like below. v17, v20 and v23 are 2-register-wide virtual registers where the first register is reserved for the message header and the second register is loaded with the indices by some prior instructions.

VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 v18, v17
VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 v21, v20
VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 v24, v23

The register allocator allocates the virtual registers as below. It reuses the source register from the second load as the destination in the third. It also uses g11 for both the source and the dest in the first load. Neither of these should cause a problem.

VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 g11, g11
VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 g12, g13
VS_OPCODE_PULL_CONSTANT_LOAD_GEN7 g13, g15

The instruction scheduler now kicks in and reorders the last two instructions. As far as it is concerned it is safe to do this because the initialisation code before the loads only writes to the top half of the source register pairs (g12, g14 and g16) and doesn't write to the lower halves so it looks like writing to those destination registers doesn't cause a collision. However the problem is that the generator actually sneaks in a write to the source register in order to set up the message header. So the code now looks like this:

mov(4)          g11<1>UD        g0<4,4,1>UD ; set up the message header
send(8)         g11<1>F         g11<4,4,1>.xD
                            sampler (0, 0, 7, 0) mlen 2 rlen 1
mov(4)          g15<1>UD        g0<4,4,1>UD ; set up the message header
send(8)         g13<1>F         g15<4,4,1>.xD
                            sampler (0, 0, 7, 0) mlen 2 rlen 1
mov(4)          g13<1>UD        g0<4,4,1>UD ; set up the message header
send(8)         g12<1>F         g13<4,4,1>.xD
                            sampler (0, 0, 7, 0) mlen 2 rlen 1

This is a problem because the third move instruction is actually overwriting the results from the second send instruction. The scheduler had no way of knowing this was going to happen because there was no dependency set up to let it know that the PULL_CONSTANT_LOAD instruction writes to one of its sources.

I think this might be a general problem with the way we handle texture sampling and I think it would effect normal texture sampling with a header such as texelOffset in a fragment shader and it's just a coincidence that it is only hit in these circumstances. However this is only a hunch because I still don't really understand the register allocator and the scheduler very well.

Maybe a good solution would be to add the MOV for the message header outside of the generator so that the dependencies would be tracked correctly. This might also allow some better optimisations to take place.

ye.tian, it would be great if you could test this patch which I think should fix the ETQW rendering error:

http://lists.freedesktop.org/archives/mesa-dev/2015-April/081896.html

(In reply to Neil Roberts from comment #28)
> ye.tian, it would be great if you could test this patch which I think should
> fix the ETQW rendering error:
> 
> http://lists.freedesktop.org/archives/mesa-dev/2015-April/081896.html

Tested on the latest nightly kernel(5ea91d) and the latest mesa(cc5860e) with this patch, this issue does not exists on skl.

This issue also does not exists on the latest mesa(cc5860e).

Ah yes, it is also already fixed on git master. A bisect points to this commit:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=588859e

I think this just happens to fix it because after that patch the registers get allocated differently and it coincidentally picks registers that work. I think the patch is still needed to fix the underlying problem and this is demonstrated by the fact that the three Piglit tests mentioned in the commit message still fail on Git master.