All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Don't use hardware acceleration on Sandybridge rev 07 hardware or earlier.
@ 2010-11-19  3:29 Matthias Hopf
  2010-11-19 21:47 ` [PATCH] Dont " Chris Wilson
  0 siblings, 1 reply; 7+ messages in thread
From: Matthias Hopf @ 2010-11-19  3:29 UTC (permalink / raw)
  To: intel-gfx

This is known to lock up the GPU even with the workaround in place.

Signed-off-by: Matthias Hopf <mhopf@suse.de>
---
 src/intel_driver.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/src/intel_driver.c b/src/intel_driver.c
index 926c7e3..be41712 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -482,6 +482,13 @@ static Bool can_accelerate_2d(struct intel_screen_private *intel)
 		if (drmIoctl(intel->drmSubFD, DRM_IOCTL_I915_GETPARAM, &gp))
 			return FALSE;
 	}
+	if (INTEL_INFO(intel)->gen == 60) {
+		struct pci_device *const device = intel->PciInfo;
+		/* Sandybridge rev07 locks up easily, even with the workaround
+		 * in place. Thus use shadowfb by default. */
+		if (device->revision < 8)
+		    return FALSE;
+	}
 
 	return TRUE;
 }
-- 
1.6.4.2

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
  2010-11-19  3:29 [PATCH] Don't use hardware acceleration on Sandybridge rev 07 hardware or earlier Matthias Hopf
@ 2010-11-19 21:47 ` Chris Wilson
  2010-11-20 15:17   ` Matthias Hopf
  0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2010-11-19 21:47 UTC (permalink / raw)
  To: Matthias Hopf, intel-gfx

On Fri, 19 Nov 2010 04:29:57 +0100, Matthias Hopf <mhopf@suse.de> wrote:
> This is known to lock up the GPU even with the workaround in place.

Before applying this patch, I'd like to know the results of using the
FORCE_WAKE write before reading the ring buffer registers. Also as we are
accumulating workarounds for SNB faster than is healthy, we should be
careful about which one we mean at the time of the comment.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
  2010-11-19 21:47 ` [PATCH] Dont " Chris Wilson
@ 2010-11-20 15:17   ` Matthias Hopf
  2010-11-21  3:59     ` Keith Packard
  0 siblings, 1 reply; 7+ messages in thread
From: Matthias Hopf @ 2010-11-20 15:17 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Nov 19, 10 21:47:48 +0000, Chris Wilson wrote:
> On Fri, 19 Nov 2010 04:29:57 +0100, Matthias Hopf <mhopf@suse.de> wrote:
> > This is known to lock up the GPU even with the workaround in place.
> 
> Before applying this patch, I'd like to know the results of using the
> FORCE_WAKE write before reading the ring buffer registers. Also as we are
> accumulating workarounds for SNB faster than is healthy, we should be
> careful about which one we mean at the time of the comment.

I know, I know. The patch is (one of) the results of the Novell-HP-Intel
workshop in Taipei this week. It turned out that rev07 is too unstable.
Keith and Eric can probably comment on this. Better than I can.

I'm currently unsure whether the FORCE_WAKE write is the workaround
Eric was testing, but we used his intel_drm_next branch for that.
Without that workaround in place the rev07 locked up basically
immediately, while with the workaround it took a while (though not very
long) to freeze the GPU.

Strictly speaking the patch is possibly not really required for
upstream, as it's only about rev07. We will use it to be able to
continue testing at Novell with these old revisions.

Thanks

CU

Matthias

-- 
Matthias Hopf <mhopf@suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat@mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
  2010-11-20 15:17   ` Matthias Hopf
@ 2010-11-21  3:59     ` Keith Packard
  2010-11-21  9:03       ` Chris Wilson
  2010-11-24  3:13       ` Zou, Nanhai
  0 siblings, 2 replies; 7+ messages in thread
From: Keith Packard @ 2010-11-21  3:59 UTC (permalink / raw)
  To: Matthias Hopf, Chris Wilson; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 803 bytes --]

On Sat, 20 Nov 2010 16:17:40 +0100, Matthias Hopf <mhopf@suse.de> wrote:

> I know, I know. The patch is (one of) the results of the Novell-HP-Intel
> workshop in Taipei this week. It turned out that rev07 is too unstable.
> Keith and Eric can probably comment on this. Better than I can.

There's a work-around in the kernel for pre rev-8 hardware that ensures
every time the blt ring is advanced by the CPU, the first command
executes a batch buffer. So the hardware is obviously quite broken.

This workaround doesn't work perfectly, and the GPU will still lock up
when executing commands out of the blt ring from time to time. As pre
rev-8 hardware is all pre-production, the workarounds should be removed
From the driver and all acceleration disabled.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
  2010-11-21  3:59     ` Keith Packard
@ 2010-11-21  9:03       ` Chris Wilson
  2010-11-24  3:13       ` Zou, Nanhai
  1 sibling, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2010-11-21  9:03 UTC (permalink / raw)
  To: Keith Packard, Matthias Hopf; +Cc: intel-gfx


On Sat, 20 Nov 2010 19:59:34 -0800, Keith Packard <keithp@keithp.com> wrote:
> On Sat, 20 Nov 2010 16:17:40 +0100, Matthias Hopf <mhopf@suse.de> wrote:
> 
> > I know, I know. The patch is (one of) the results of the Novell-HP-Intel
> > workshop in Taipei this week. It turned out that rev07 is too unstable.
> > Keith and Eric can probably comment on this. Better than I can.
> 
> There's a work-around in the kernel for pre rev-8 hardware that ensures
> every time the blt ring is advanced by the CPU, the first command
> executes a batch buffer. So the hardware is obviously quite broken.
> 
> This workaround doesn't work perfectly, and the GPU will still lock up
> when executing commands out of the blt ring from time to time. As pre
> rev-8 hardware is all pre-production, the workarounds should be removed
> From the driver and all acceleration disabled.

Ah ha! If it's the BLT workaround, then yes that can die in a very hot
fire. Thanks for the explanation.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
  2010-11-21  3:59     ` Keith Packard
  2010-11-21  9:03       ` Chris Wilson
@ 2010-11-24  3:13       ` Zou, Nanhai
  2010-12-05 11:44         ` Chris Wilson
  1 sibling, 1 reply; 7+ messages in thread
From: Zou, Nanhai @ 2010-11-24  3:13 UTC (permalink / raw)
  To: Keith Packard, Matthias Hopf, Chris Wilson; +Cc: intel-gfx

>>-----Original Message-----
>>From: intel-gfx-bounces+nanhai.zou=intel.com@lists.freedesktop.org
>>[mailto:intel-gfx-bounces+nanhai.zou=intel.com@lists.freedesktop.org] On
>>Behalf Of Keith Packard
>>Sent: 2010年11月21日 12:00
>>To: Matthias Hopf; Chris Wilson
>>Cc: intel-gfx@lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [PATCH] Dont use hardware acceleration on Sandybridge
>>rev 07 hardware or earlier.
>>
>>On Sat, 20 Nov 2010 16:17:40 +0100, Matthias Hopf <mhopf@suse.de> wrote:
>>
>>> I know, I know. The patch is (one of) the results of the Novell-HP-Intel
>>> workshop in Taipei this week. It turned out that rev07 is too unstable.
>>> Keith and Eric can probably comment on this. Better than I can.
>>
>>There's a work-around in the kernel for pre rev-8 hardware that ensures
>>every time the blt ring is advanced by the CPU, the first command
>>executes a batch buffer. So the hardware is obviously quite broken.
>>
>>This workaround doesn't work perfectly, and the GPU will still lock up
>>when executing commands out of the blt ring from time to time. As pre
>>rev-8 hardware is all pre-production, the workarounds should be removed
>>From the driver and all acceleration disabled.
>>

Hi,
	I can not reproduce the issue here on a pre rev-8 system.
Dose it still hang if disable RC6?
Set 0 for nit 18 in 0xA090?

Thanks
Zou Nanhai
>>--
>>keith.packard@intel.com
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] Dont use hardware acceleration on Sandybridge rev 07 hardware or earlier.
  2010-11-24  3:13       ` Zou, Nanhai
@ 2010-12-05 11:44         ` Chris Wilson
  0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2010-12-05 11:44 UTC (permalink / raw)
  To: Zou, Nanhai, Keith Packard, Matthias Hopf; +Cc: intel-gfx

We had two independent reports of rev07 failing even with the BLT
workaround in place, so I applied the patch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-12-05 11:44 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-19  3:29 [PATCH] Don't use hardware acceleration on Sandybridge rev 07 hardware or earlier Matthias Hopf
2010-11-19 21:47 ` [PATCH] Dont " Chris Wilson
2010-11-20 15:17   ` Matthias Hopf
2010-11-21  3:59     ` Keith Packard
2010-11-21  9:03       ` Chris Wilson
2010-11-24  3:13       ` Zou, Nanhai
2010-12-05 11:44         ` Chris Wilson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.