Jani Monoses writes:
In a dual monitor setup on a laptop with the card
01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P
[Radeon Mobility X600]
( 01:00.0 0300: 1002:3150 )
on resuming from suspend to RAM the machine locks up, no pings, no
caps-lock toggling, blank screen.
Jani Monoses writes:
Thanks. I actually used that to narrow the cause down to the video
card, but I don't remember seeing detailed line info in that dmesg
which would point to a location within the radeon driver.
Yes. You need to add more TRACE_RESUMEs to the code to further
narrow down the
Fixed up a pSrc/pDst typo in the previous patch, as discovered by
Michel. http://lists.x.org/archives/xorg-driver-ati/2010-August/016956.html
From a79f8aef8d420cd6606db06eba654dd8d4677d00 Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sun, 22 Aug 2010 21:02:45 +1200
Subject
Updated to apply cleanly after the corrected part 4.
From 89f42d148e826a0f774256fedc1ebce02cd8be3a Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sun, 22 Aug 2010 22:28:06 +1200
Subject: [PATCH 5/6] radeon: complete UTS and DFS even when a scratch BO is not
necessary
Turns
Alex Deucher writes:
2010/9/1 xm...@karlt.net:
Michel Dänzer writes:
, still it would be good to make some additional measurements
to make sure there aren't any bad regressions.
I'll look into it. Let me know if there is a subset of x11perf
tests that is interesting here. I just saw
Michel Dänzer writes:
@@ -593,6 +596,10 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int
y, int w,
if ((src_domain (RADEON_GEM_DOMAIN_GTT | RADEON_GEM_DOMAIN_VRAM)) ==
(RADEON_GEM_DOMAIN_GTT | RADEON_GEM_DOMAIN_VRAM))
src_domain = 0;
+#if X_BYTE_ORDER ==
in the methods.
so changes to one
patch may require changing an otherwise unrelated patch as well.
OK. I won't submit another part 5 until I have feedback on the
earlier parts.
On Mon, 2010-08-23 at 19:25 +1200, Karl Tomlinson wrote:
I
Michel Dänzer writes:
On Mon, 2010-08-23 at 18:27 +1200, Karl Tomlinson wrote:
radeon_bo_is_busy() may return without setting the domain out-parameter.
If this happens, then download via a scratch GTT BO to avoid CPU VRAM read.
I'm on the fence about this one. I can see how it could help
From 47543731f717daacb2e8f102ed0ac7dd655eb3d1 Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sat, 21 Aug 2010 22:29:34 +1200
Subject: [PATCH 2/6] FinishAccess_CS: set bo_mapped to FALSE on unmap
This is actually only necessary when PrepareAccess may behave differently
From ee9b8c23c6e0f4b60ef6b35b55cc2a2aeef4019a Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sun, 22 Aug 2010 22:28:06 +1200
Subject: [PATCH 5/6] radeon: complete UTS and DFS even when a scratch BO is not necessary
Turns on the big-endian paths even for little-endian systems
:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sun, 22 Aug 2010 22:46:33 +1200
Subject: [PATCH 6/6] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in
VRAM
This avoids costly CPU VRAM reads and lets EXA manage a system memory cache
of the portions of pixmaps needed for unaccelerated
From df63f153eb9e8ef380c7fc1f754183d646da9eba Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sat, 21 Aug 2010 21:44:39 +1200
Subject: [PATCH 1/6] DownloadFromScreenCS: download via a scratch BO if pixmap
domain is unknown
radeon_bo_is_busy() may return without setting
(A subsequent patch proposes removing #if X_BYTE_ORDER.)
From c486d7eb68edf3b4c7cfd59da50f30898f0b36f2 Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sun, 22 Aug 2010 20:04:42 +1200
Subject: [PATCH 3/6] RADEONDownloadFromScreenCS: flush CS writes before mapping
BO for read
From f57a1e18dfbddaf30a92fee82a3bf286f541fae3 Mon Sep 17 00:00:00 2001
From: Karl Tomlinson kar...@karlt.net
Date: Sun, 22 Aug 2010 21:02:45 +1200
Subject: [PATCH 4/6] radeon: complete big endian UTS and DFS even when scratch allocation fails.
On big endian systems, PrepareAccess will fail when
14 matches
Mail list logo
