G72 doesn't need ExaCopy workaround

Hi,

I have a G72M wich is very slow when the workaround in NVExaCopy kicks in. It works much better with the attached patch.

I wonder if that workaround is really needed.

Greetings,
Jaime

From a7d1e23dcb6713230c15aa97968890c67fc11f4d Mon Sep 17 00:00:00 2001
From: Jaime Velasco Juan <[email protected]>
Date: Sat, 20 Oct 2007 12:01:59 +0100
Subject: [PATCH] G72 doesn't need ExaCopy workaround

---
 src/nv_exa.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

index d88d85a..b403072 100644
@@ -283,7 +283,6 @@ static void NVExaCopy(PixmapPtr pDstPixmap,
 	if ( ((abs(srcY - dstY)< 16)||(abs(srcX-dstX)<16)) &&
 		((((pNv->Chipset & 0xfff0) == CHIPSET_G70) ||
 		 ((pNv->Chipset & 0xfff0) == CHIPSET_G71) ||
-		 ((pNv->Chipset & 0xfff0) == CHIPSET_G72) ||
 		 ((pNv->Chipset & 0xfff0) == CHIPSET_G73) ||
 		 ((pNv->Chipset & 0xfff0) == CHIPSET_C512))) )
 	{

1.5.3.3

_______________________________________________
Nouveau mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/nouveau

It's entirely possible that your card does not have the bug.

Maybe i can figure out what the original card was with this issue.

Anyone else have an opinion on how to deal with this? (remove the single entry, or try to narrow it down even further, etc)

Maarten.

Yeah, we don't know precisely under what circumstances it's triggered. It seems to be related to texture data caching somehow, but that's all we know.

Maybe i can figure out what the original card was with this issue.

We could try to use the 3D engine to do copies on nv40, provided there's no issue with texture caching when doing copies to/from the same surface.

Of course, the best solution is to look at how nvidia implement this.

Stephane

_______________________________________________
Nouveau mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/nouveau