[Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/20/2011 01:24 AM, Nicolas Kalkhof wrote:
> Hi Ian,
> 
> ok I've definately nailed the issue down to the "i915_enable_rc6" parameter in i915_drv.c
> Someone disabled this parameter and that causes the depthbuffer issue. I've enabled the switch by setting i915_enable_rc6=1; and the problem dissapeared.
> 
> glxinfo | grep "OpenGL renderer" shows:
> OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
> 
> lspci -vn | grep VGA yields:
> 00:02.0 0300: 8086:0126 (rev 09) (prog-if 00 [VGA controller])
> 
> My CPU is a SNB I72620M with a 3000 graphics. No other GPU present.
> 
> Stupid question: Can I file a bug report on https://bugs.freedesktop.org or on  https://bugzilla.kernel.org/

bugzilla.kernel.org is the right place.  Please include all of the
information from this e-mail and the image showing the corruption.

> -----Ursprüngliche Nachricht-----
> Von: "Ian Romanick" <idr at freedesktop.org>
> Gesendet: Jul 19, 2011 11:08:14 PM
> An: "Nicolas Kalkhof" <nkalkhof at web.de>
> Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with OpenGL games
> 
> On 07/19/2011 01:21 PM, Nicolas Kalkhof wrote:
>>>> Hi all,
>>>>
>>>> ok I've nailed the issue down to 3.0.0-rc7 and 3.0.0-rc7-git1. I suspect that the changes made in
>>>> drivers/gpu/drm/i915/i915_dma.c are the cause of the problem.
>>>>
>>>> http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv3.0%2Fsnapshots%2Fpatch-3.0-rc7-git1.bz2;z=14
>>>>
>>>> Any Clues?
> 
> Okay, so that's the commit below, which changes some error clean-up
> paths. That is also odd. What *exact* GPU do you have? Specificially,
> what's the output of
> 
> glxinfo | grep "OpenGL renderer"
> 
> and
> 
> lspci -vn | grep VGA
> 
> Does this appear in all games or just certain games? If it's just in
> certain games, which ones?
> 
> commit a7b85d2aa63ed09cd5a4a640772b3272f5ac7caa
> Author: Keith Packard <keithp at keithp.com>
> Date: Sun Jul 10 13:12:17 2011 -0700
> 
> drm/i915: Clean up i915_driver_load failure path
> 
> i915_driver_load adds a write-combining MTRR region for the GTT
> aperture to improve memory speeds through the aperture. If
> i915_driver_load fails after this, it would not have cleaned up the
> MTRR. This shouldn't cause any problems, except for consuming an MTRR
> register. Still, it's best to clean up completely in the failure path,
> which is easily done by calling mtrr_del if the mtrr was successfully
> allocated.
> 
> i915_driver_load calls i915_gem_load which register
> i915_gem_inactive_shrink. If i915_driver_load fails after calling
> i915_gem_load, the shrinker will be left registered. When called, it
> will access freed memory and crash. The fix is to unregister the
> shrinker in the
> failure path using code duplicated from i915_driver_unload.
> 
> i915_driver_load also has some incorrect gotos in the error cleanup
> paths:
> 
> * After failing to initialize the GTT (which cannot happen, btw,
> intel_gtt_get returns a fixed (non-NULL) value), it tries to
> free the uninitialized WC IO mapping. Fixed this by changing the
> target from out_iomapfree to out_rmmap
> 
> Signed-off-by: Keith Packard <keithp at keithp.com>
> Tested-by: Lin Ming <ming.m.lin at intel.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4m6yAACgkQX1gOwKyEAw/6MQCgjs/YWI3rpwN8XsgHy/rwuq5P
c84AnjsjBjudlE9QZBuLFhuZgW+giw+/
=eJ0i
-----END PGP SIGNATURE-----