Bug 43037

Summary:	Doom 3 under Sandy Bridge caused issues : hang, memory corruption...
Product:	Mesa	Reporter:	antistress <anti-stress>
Component:	Drivers/DRI/i965	Assignee:	Ian Romanick <idr>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	67224

Description antistress 2011-11-17 11:38:37 UTC

From phoronix.com article published on November 17, 2011
http://www.phoronix.com/scan.php?page=article&item=doom3_linux_mesa

"For the open-source driver testing, all of the important components were pulled from Git master on the morning of 16 November. This includes Mesa 7.12-devel, Linux 3.2, libdrm, xf86-video-intel, xf86-video-ati, and xf86-video-nouveau atop an Ubuntu 11.10 x86_64 installation

[...] First to be tested was the integrated Intel HD 3000 graphics from the Core i5 Sandy Bridge. [...] Running Doom 3 in a stock driver configuration for the Intel Linux graphics under Sandy Bridge caused issues. There were multiple times where the system would hang and there would be visible memory corruption to varying extents.

There were also times there would not be frame-buffer corruption, but the Sandy Bridge graphics processor would be hung and then restarted by Intel's DRM kernel driver (as reported by dmesg). Sometimes there would be the GPU being hung twice, which was not gracefully recovered.

[...] Even with this latest-generation of Intel HD graphics and the very latest Linux driver code, the Doom 3 experience is not really acceptable for gamers due to the frequent problems and overall slow performance."

Thanks

Comment 1 Kenneth Graunke 2012-05-09 01:23:36 UTC

Pretty sure this is fixed...Ian's able to run Doom 3 now.  Not sure what it was, but we did apply a lot of workarounds for known hardware errata in the meantime.

Comment 2 Ian Romanick 2012-05-09 10:12:37 UTC

This is very much still an issue.  On both the 8.0 branch and master I have to run with HiZ disabled.

Comment 3 Eric Anholt 2012-08-13 05:52:06 UTC

Ian: is this still an issue for you, after the hiz hang fix?

Comment 4 Eric Anholt 2013-02-15 05:40:57 UTC

The sparse sampler fix from this fall may also matter.  Someone should retest.

Comment 5 Tapani Pälli 2013-07-25 05:23:55 UTC

I've tested with Sandybridge and Mesa master (0acf3a8407...). The game runs fine, there is quite a lot of "Mesa: User error: GL_INVALID_VALUE in glScissor" printed on console but no rendering artifacts visible. Is there some particular level that might trigger issues?

Comment 6 Tapani Pälli 2013-07-26 11:13:33 UTC

I've tested today Doom3 on Haswell (Mesa 9.2, libdrm 2.4.46), no visual corruptions or other problems visible, works very well. With MESA_DEBUG=1 I can see those same glScissor errors on console. Will also test the game against Mesa master.

Comment 7 Tapani Pälli 2013-07-26 12:11:12 UTC

worked fine also with mesa ~master (df530829f757a8968389427eb26f45a0d46623fa)

Comment 8 Ian Romanick 2013-07-27 05:44:40 UTC

Tapani,

Can you check why it's getting the error in glScissor?  It's probably Doom's bug (and is a separate issue regardless).

My inclination is that we should close this bug WORKSFORME.

Comment 9 Tapani Pälli 2013-07-29 05:52:18 UTC

Most of the time it's providing sane values for glScissor but now and then some default or min/max values from somewhere:

--- 8< ---
...
--> glScissor 118 0 353 450
--> glScissor 169 0 359 509
--> glScissor 308 376 106 108
--> glScissor 0 0 745 768
--> glScissor 0 0 1024 768
--> glScissor 32000 32000 -63999 -63999
Mesa: User error: GL_INVALID_VALUE in glScissor
--> glScissor 0 0 1024 768
--> glScissor 430 388 130 380
--> glScissor 0 0 1024 768
...
--- 8< ---

so that is an separate application issue. This bug is resolved.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.