Graphics corruption issues

Here is a patch for some graphics corruption issues I discovered since this commit:

commit 1cc2c2c44ac72460cf1c4e6bdc13c612235809c9

Author: Chris Wilson <[email protected]>
Date:   Wed Apr 14 11:18:25 2010 +0100

i830: Use pixman_blt directly for performing the in-memory copy

In order to avoid an infinite recursion after enabling CopyArea to use the put_image acceleration to either stream a blit or to copy in-place, we cannot call CopyArea from put_image for the fallback path. Instead, we can simply call pixman_blt directly, which coincidentally is a tiny bit faster.

I've also attached a cosmetic clean-up in the same area.

Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

From: Peter Clifton <[email protected]>
Date: Thu, 22 Apr 2010 18:59:49 +0100
Subject: [PATCH 1/2] i830: pixman_blt may fail, ensure we pass this result down

Fixes visual corruption noticed in the background of OpenOffice Impress slides and slide preview seen since commit 1cc2c2c44ac72460cf1c4e6bdc13c612235809c9

---
 src/i830_uxa.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

index 984069e..4f0c250 100644
@@ -832,17 +832,16 @@ static Bool i830_uxa_put_image(PixmapPtr pixmap,
 			return FALSE;
 		}
 
-		pixman_blt((uint32_t *)src, priv->bo->virtual,
-			   src_pitch / sizeof(uint32_t),
-			   pixmap->devKind / sizeof(uint32_t),
-			   pixmap->drawable.bitsPerPixel,
-			   pixmap->drawable.bitsPerPixel,
-			   0, 0,
-			   x, y,
-			   w, h);
+		ret = pixman_blt((uint32_t *)src, priv->bo->virtual,
+				 src_pitch / sizeof(uint32_t),
+				 pixmap->devKind / sizeof(uint32_t),
+				 pixmap->drawable.bitsPerPixel,
+				 pixmap->drawable.bitsPerPixel,
+				 0, 0,
+				 x, y,
+				 w, h);
 
 		drm_intel_gem_bo_unmap_gtt(priv->bo);
-		ret = TRUE;
 	}
 
 	return ret;

1.7.0.4

From: Peter Clifton <[email protected]>
Date: Thu, 22 Apr 2010 19:01:13 +0100
Subject: [PATCH 2/2] i830: Use the i830_pixmap_pitch() helper function for clarity

---
 src/i830_uxa.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

index 4f0c250..38c98fe 100644
@@ -774,6 +774,7 @@ static Bool i830_uxa_put_image(PixmapPtr pixmap,
 	struct intel_pixmap *priv;
 	GCPtr gc;
 	Bool ret;
+	int dst_pitch;
 
 	if (x == 0 && y == 0 &&
 	    w == pixmap->drawable.width &&

@@ -832,9 +833,11 @@ static Bool i830_uxa_put_image(PixmapPtr pixmap,
 			return FALSE;
 		}
 
+		dst_pitch = i830_pixmap_pitch(pixmap);
+
 		ret = pixman_blt((uint32_t *)src, priv->bo->virtual,
 				 src_pitch / sizeof(uint32_t),
-				 pixmap->devKind / sizeof(uint32_t),
+				 dst_pitch / sizeof(uint32_t),
 				 pixmap->drawable.bitsPerPixel,
 				 pixmap->drawable.bitsPerPixel,
 				 0, 0,

1.7.0.4

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

They were attached, with a suggested viewing hint of inline - so I think your original comment was correct.

I'm not familiar with how to send mails straight from git, and I thought non-attached versions of the patch pasted into my mail client (evolution) would be more likely to produce a corrupt patch, munging tabs, spaces etc..

Thanks for your comments and testing though. I'm not entirely sure if returning FALSE when pixman can't do a blit is sufficient, but it "seems to help" here. Perhaps Chris can comment.

Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

FWIW, we're actually pretty awful at patch triage in gEDA (the project I work on).. there are patches languishing in the bug tracker, and in various people's INBOX, so I can easily relate to the issue.

Sadly, in our case.. the more complex the patch (perhaps the more effort the submitter has had to go to fix the bug / add a feature), the more likely it is to sit in limbo waiting for someone sufficiently familiar with the existing code to review the patch.

Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)