Re: evergreen acceleration support
On 08/20/2010 05:21 PM, Alex Deucher wrote: I've just pushed out the initial evergreen (radeon HD5xxx) acceleration support for EXA and Xv to the evergreen_accel branch of xf86-video-ati. Full support for EXA and Xv is available. To use it, you'll need 2.6.35 with kms enabled. There are still some GPU hangs in some cases that we haven't sorted out yet. Richard will be pushing out mesa support as soon as he finishes rebasing his tree against mesa master. We'll be releasing updated register specs eventually, but as you can see, most of the registers and bit fields are the same as r6xx/r7xx. Happy Hacking! Alex Crashes for me when the boot scripts start 'xdm'. Attached tarball has 'dmesg' output, copy of 'Xorg.0.log', and copy of 'xdm.log' (with same backtrace as Xorg.0.log). Should I put this on Bugzilla, or is evergreen-accel too new? Hardware: Radeon HD 5750 Software: linux 2.6.35.2 [merged with drm-radeon-testing merged up to c9f9e91; have also reverted 5b1714d, and added patch to fix pink vert. line -- not sure if there are git commits available yet] libdrm 2.4.21 mesa 7.9-devel, git be99100 xorg-server1.9.0 xf86-video-radeon 6.13.99, branch evergreen-accel (bdd41fec) Note: libdrm was built against a previous kernel; I can rebuild it tomorrow if this is a likely cause of the crash. Except for this handful of packages I rebuild myself, I am using Debian unstable/experimental. Many of the packages are provided with *-dbg versions, but 'xdm' is not one of those. Possibly I could attempt to rebuild an unstripped version of 'xdm' myself; I certainly can install debug versions of xorg-server and radeon, but will the backtrace alone make use of the debugging symbols? I'm not quite sure how I can use 'gdb' in a situation like this to get a better backtrace, but if there's a way I'd be glad to try. Thanks, Dave W. radeon.evergreen-accel.hd5750.crashlogs.tar.bz2 Description: application/bzip ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 29575] My radeon 4570 mobile not work under linux for kms (kernel mode settings)
https://bugs.freedesktop.org/show_bug.cgi?id=29575 --- Comment #8 from BRULE Herman alpha_one_...@first-world.info 2010-08-22 23:29:32 PDT --- Other behavior, for have 3D acceleration I need activate in the kernel: Device Drivers - Graphics support - VGA Arbritration Device Drivers - Graphics support - Laptop Hybrid Graphics - GPU switching support And disable: Device Drivers - Graphics support - DRM - kms for radeon -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 3/6] RADEONDownloadFromScreenCS: flush CS writes before mapping
BO for read
In-Reply-To: 8762z1260w@karlt.net (Karl Tomlinson's message of Mon, 23
Aug 2010 18:32:31 +1200)
References: 87d3t92692@karlt.net 8762z1260w@karlt.net
From: Karl Tomlinson xm...@karlt.net
Date: Mon, 23 Aug 2010 18:39:07 +1200
Message-ID: 87vd71zvck.fsf...@karlt.net
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary==-=-=
--=-=-=
(A subsequent patch proposes removing #if X_BYTE_ORDER.)
--=-=-=
Content-Disposition: inline;
filename=0003-RADEONDownloadFromScreenCS-flush-CS-writes-before-ma.patch
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
If unflushed CS operations write to the pixmap BO, then these need to be
flushed before mapping the BO for read. This currently only affects big
endian systems and only when the operation writes to the GTT domain.
---
src/radeon_exa_funcs.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index a82e416..d02c787 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -567,6 +567,9 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
unsigned bpp = pSrc-drawable.bitsPerPixel;
uint32_t scratch_pitch = RADEON_ALIGN(w * bpp / 8, 64);
uint32_t swap = RADEON_HOST_DATA_SWAP_NONE;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+Bool flush = FALSE;
+#endif
Bool r;
if (bpp 8)
@@ -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 == X_BIG_ENDIAN
+ else /* A write may be scheduled */
+ flush = TRUE;
+#endif
}
if (!src_domain)
@@ -631,11 +638,14 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
scratch_pitch 16, x, y, 0, 0, w, h,
RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT,
RADEON_GEM_DOMAIN_GTT);
-FLUSH_RING();
-
#if X_BYTE_ORDER == X_BIG_ENDIAN
+flush = TRUE;
+
copy:
+if (flush)
#endif
+ FLUSH_RING();
+
r = radeon_bo_map(scratch, 0);
if (r) {
r = FALSE;
--
1.7.1
--=-=-=--
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 4/6] radeon: complete big endian UTS and DFS even when scratch a
llocation fails
In-Reply-To: 87vd71zvck.fsf...@karlt.net (Karl Tomlinson's message of Mon,
23 Aug 2010 18:39:07 +1200)
References: 87d3t92692@karlt.net 8762z1260w@karlt.net
87vd71zvck.fsf...@karlt.net
From: Karl Tomlinson xm...@karlt.net
Date: Mon, 23 Aug 2010 18:41:39 +1200
Message-ID: 87r5hpzv8c.fsf...@karlt.net
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0004-radeon-complete-big-endian-UTS-and-DFS-even-when-scr.patch
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 byte-swapping is required
so UploadToScreen and DownloadFromScreen cannot rely on fallback to
PrepareAccess.
When scratch BO space allocation fails, this patch merely adds simple fallback
to direct CPU access without any GPU blit. This sometimes requires a CS flush
even in UploadToScreen. (No allocation retry after a flush is added here.)
---
src/radeon_exa_funcs.c | 120 +--
1 files changed, 84 insertions(+), 36 deletions(-)
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index d02c787..8c9a874 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -459,7 +459,8 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int w,
int h,
ScreenPtr pScreen = pDst-drawable.pScreen;
RINFO_FROM_SCREEN(pScreen);
struct radeon_exa_pixmap_priv *driver_priv;
-struct radeon_bo *scratch;
+struct radeon_bo *scratch = NULL;
+struct radeon_bo *copy_dst;
unsigned char *dst;
unsigned size;
uint32_t datatype = 0;
@@ -467,7 +468,12 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int
w, int h,
uint32_t dst_pitch_offset;
unsigned bpp = pDst-drawable.bitsPerPixel;
uint32_t scratch_pitch = RADEON_ALIGN(w * bpp / 8, 64);
+uint32_t copy_pitch;
uint32_t swap = RADEON_HOST_DATA_SWAP_NONE;
+int ret;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+Bool flush = TRUE;
+#endif
Bool r;
int i;
@@ -490,54 +496,78 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int
w, int h,
#endif
/* If we know the BO won't be busy, don't bother */
-if (!radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)
- !radeon_bo_is_busy(driver_priv-bo, dst_domain)) {
#if X_BYTE_ORDER == X_BIG_ENDIAN
- /* Can't return FALSE here if we need to swap bytes */
- if (swap != RADEON_HOST_DATA_SWAP_NONE
- driver_priv-bo != info-front_bo) {
- scratch = driver_priv-bo;
- scratch_pitch = pDst-devKind;
- goto copy;
- }
+copy_dst = driver_priv-bo;
+copy_pitch = pSrc-devKind;
#endif
- return FALSE;
+if (!radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ flush = FALSE;
+#endif
+ if (!radeon_bo_is_busy(driver_priv-bo, dst_domain)) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ /* Can't return FALSE here if we need to swap bytes */
+ if (swap != RADEON_HOST_DATA_SWAP_NONE
+ driver_priv-bo != info-front_bo) {
+ goto copy;
+ }
+#endif
+ return FALSE;
+ }
}
size = scratch_pitch * h;
scratch = radeon_bo_open(info-bufmgr, 0, size, 0, RADEON_GEM_DOMAIN_GTT,
0);
if (scratch == NULL) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ if (swap != RADEON_HOST_DATA_SWAP_NONE
+ driver_priv-bo != info-front_bo) {
+ goto copy;
+ }
+#endif
return FALSE;
}
radeon_cs_space_reset_bos(info-cs);
radeon_add_pixmap(info-cs, pDst, 0, RADEON_GEM_DOMAIN_VRAM);
radeon_cs_space_add_persistent_bo(info-cs, scratch,
RADEON_GEM_DOMAIN_GTT, 0);
-r = radeon_cs_space_check(info-cs);
-if (r) {
+ret = radeon_cs_space_check(info-cs);
+if (ret) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ if (swap != RADEON_HOST_DATA_SWAP_NONE
+ driver_priv-bo != info-front_bo) {
+ goto copy;
+ }
+#endif
r = FALSE;
goto out;
}
-
+copy_dst = scratch;
+copy_pitch = scratch_pitch;
#if X_BYTE_ORDER == X_BIG_ENDIAN
+flush = FALSE;
+
copy:
+if (flush)
+ radeon_cs_flush_indirect(pScrn);
#endif
-r = radeon_bo_map(scratch, 0);
-if (r) {
+
+ret = radeon_bo_map(copy_dst, 0);
+if (ret) {
r = FALSE;
goto out;
}
r = TRUE;
size = w * bpp / 8;
-dst = scratch-ptr;
-if (scratch == driver_priv-bo)
- dst += y * scratch_pitch + x * bpp / 8;
+dst = copy_dst-ptr;
+if (copy_dst == driver_priv-bo)
+ dst += y * copy_pitch + x * bpp / 8;
for (i = 0; i h; i++) {
-RADEONCopySwap(dst + i * scratch_pitch,
[PATCH 2/6] FinishAccess_CS: set bo_mapped to FALSE on unmap
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 on different calls with the same pixmap, which currently doesn't happen. However resetting bo_mapped is necessary to let PrepareAccess (with mixed pixmaps) choose to fail based on whether the pixmap is in VRAM (to avoid CPU reads). --- src/radeon_exa.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/radeon_exa.c b/src/radeon_exa.c index 814c864..bf7cb88 100644 --- a/src/radeon_exa.c +++ b/src/radeon_exa.c @@ -323,6 +323,7 @@ void RADEONFinishAccess_CS(PixmapPtr pPix, int index) return; radeon_bo_unmap(driver_priv-bo); +driver_priv-bo_mapped = FALSE; pPix-devPrivate.ptr = NULL; } -- 1.7.1 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/6] DownloadFromScreenCS: download via a scratch BO if pixmap d
omain is unknown
From: Karl Tomlinson xm...@karlt.net
Mail-Followup-To: xorg-driver-ati@lists.x.org
Date: Mon, 23 Aug 2010 18:27:37 +1200
Message-ID: 87d3t92692@karlt.net
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline;
filename=0001-DownloadFromScreenCS-download-via-a-scratch-BO-if-pi.patch
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 the domain out-parameter.
If this happens, then download via a scratch GTT BO to avoid CPU VRAM read.
---
src/r600_exa.c |2 +-
src/radeon_exa_funcs.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/r600_exa.c b/src/r600_exa.c
index d6e98ff..9b7a0c9 100644
--- a/src/r600_exa.c
+++ b/src/r600_exa.c
@@ -1885,7 +1885,7 @@ R600DownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
if (!src_domain)
radeon_bo_is_busy(driver_priv-bo, src_domain);
-if (src_domain != RADEON_GEM_DOMAIN_VRAM)
+if (src_domain ~(uint32_t)RADEON_GEM_DOMAIN_VRAM)
return FALSE;
size = scratch_pitch * h;
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index 2df6ccb..a82e416 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -598,7 +598,7 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
if (!src_domain)
radeon_bo_is_busy(driver_priv-bo, src_domain);
-if (src_domain != RADEON_GEM_DOMAIN_VRAM) {
+if (src_domain ~(uint32_t)RADEON_GEM_DOMAIN_VRAM) {
#if X_BYTE_ORDER == X_BIG_ENDIAN
/* Can't return FALSE here if we need to swap bytes */
if (swap != RADEON_HOST_DATA_SWAP_NONE) {
--
1.7.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 5/6] radeon: complete UTS and DFS even when a scratch BO is not necessary
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, and adds similar
paths to the r6xx/r7xx functions.
This makes UTS and DFS reliable, which will let PrepareAccess (with mixed
pixmaps) choose to fail based on whether the pixmap is in VRAM (to avoid CPU
reads).
---
src/r600_exa.c | 110
src/radeon_exa_funcs.c | 74
2 files changed, 83 insertions(+), 101 deletions(-)
diff --git a/src/r600_exa.c b/src/r600_exa.c
index 9b7a0c9..8544034 100644
--- a/src/r600_exa.c
+++ b/src/r600_exa.c
@@ -1772,13 +1772,18 @@ R600UploadToScreenCS(PixmapPtr pDst, int x, int y, int w, int h,
RADEONInfoPtr info = RADEONPTR(pScrn);
struct radeon_accel_state *accel_state = info-accel_state;
struct radeon_exa_pixmap_priv *driver_priv;
-struct radeon_bo *scratch;
+struct radeon_bo *scratch = NULL;
+struct radeon_bo *copy_dst;
+unsigned char *dst;
unsigned size;
uint32_t dst_domain;
int bpp = pDst-drawable.bitsPerPixel;
uint32_t scratch_pitch = RADEON_ALIGN(w * bpp / 8, 256);
+uint32_t copy_pitch;
uint32_t src_pitch_hw = scratch_pitch / (bpp / 8);
uint32_t dst_pitch_hw = exaGetPixmapPitch(pDst) / (bpp / 8);
+int ret;
+Bool flush = TRUE;
Bool r;
int i;
struct r600_accel_object src_obj, dst_obj;
@@ -1788,15 +1793,19 @@ R600UploadToScreenCS(PixmapPtr pDst, int x, int y, int w, int h,
driver_priv = exaGetPixmapDriverPrivate(pDst);
-/* If we know the BO won't be busy, don't bother */
-if (!radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)
- !radeon_bo_is_busy(driver_priv-bo, dst_domain))
- return FALSE;
+/* If we know the BO won't be busy, don't bother with a scratch */
+copy_dst = driver_priv-bo;
+copy_pitch = pDst-devKind;
+if (!radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)) {
+ flush = FALSE;
+ if (!radeon_bo_is_busy(driver_priv-bo, dst_domain))
+ goto copy;
+}
size = scratch_pitch * h;
scratch = radeon_bo_open(info-bufmgr, 0, size, 0, RADEON_GEM_DOMAIN_GTT, 0);
if (scratch == NULL) {
- return FALSE;
+ goto copy;
}
src_obj.pitch = src_pitch_hw;
@@ -1821,33 +1830,45 @@ R600UploadToScreenCS(PixmapPtr pDst, int x, int y, int w, int h,
dst_obj,
accel_state-copy_vs_offset, accel_state-copy_ps_offset,
3, 0x)) {
-r = FALSE;
-goto out;
+goto copy;
}
+copy_dst = scratch;
+copy_pitch = scratch_pitch;
+flush = FALSE;
+
+copy:
+if (flush)
+ radeon_cs_flush_indirect(pScrn);
-r = radeon_bo_map(scratch, 0);
-if (r) {
+ret = radeon_bo_map(copy_dst, 0);
+if (ret) {
r = FALSE;
goto out;
}
r = TRUE;
size = w * bpp / 8;
+dst = copy_dst-ptr;
+if (copy_dst == driver_priv-bo)
+ dst += y * copy_pitch + x * bpp / 8;
for (i = 0; i h; i++) {
-memcpy(scratch-ptr + i * scratch_pitch, src, size);
+memcpy(dst + i * copy_pitch, src, size);
src += src_pitch;
}
-radeon_bo_unmap(scratch);
+radeon_bo_unmap(copy_dst);
-if (info-accel_state-vsync)
- RADEONVlineHelperSet(pScrn, x, y, x + w, y + h);
+if (copy_dst == scratch) {
+ if (info-accel_state-vsync)
+ RADEONVlineHelperSet(pScrn, x, y, x + w, y + h);
-/* blit from gart to vram */
-R600DoPrepareCopy(pScrn);
-R600AppendCopyVertex(pScrn, 0, 0, x, y, w, h);
-R600DoCopyVline(pDst);
+ /* blit from gart to vram */
+ R600DoPrepareCopy(pScrn);
+ R600AppendCopyVertex(pScrn, 0, 0, x, y, w, h);
+ R600DoCopyVline(pDst);
+}
out:
-radeon_bo_unref(scratch);
+if (scratch)
+ radeon_bo_unref(scratch);
return r;
}
@@ -1859,13 +1880,17 @@ R600DownloadFromScreenCS(PixmapPtr pSrc, int x, int y, int w,
RADEONInfoPtr info = RADEONPTR(pScrn);
struct radeon_accel_state *accel_state = info-accel_state;
struct radeon_exa_pixmap_priv *driver_priv;
-struct radeon_bo *scratch;
+struct radeon_bo *scratch = NULL;
+struct radeon_bo *copy_src;
unsigned size;
uint32_t src_domain = 0;
int bpp = pSrc-drawable.bitsPerPixel;
uint32_t scratch_pitch = RADEON_ALIGN(w * bpp / 8, 256);
+uint32_t copy_pitch;
uint32_t dst_pitch_hw = scratch_pitch / (bpp / 8);
uint32_t src_pitch_hw = exaGetPixmapPitch(pSrc) / (bpp / 8);
+int ret;
+Bool flush = FALSE;
Bool r;
struct r600_accel_object src_obj, dst_obj;
@@ -1874,24 +1899,28 @@ R600DownloadFromScreenCS(PixmapPtr pSrc, int x, int y, int w,
driver_priv = exaGetPixmapDriverPrivate(pSrc);
-/* If we know the BO won't end up in VRAM anyway, don't bother */
+/* If we know the BO won't end up in
[Bug 29575] My radeon 4570 mobile not work under linux for kms (kernel mode settings)
https://bugs.freedesktop.org/show_bug.cgi?id=29575 --- Comment #9 from Alex Deucher ag...@yahoo.com 2010-08-23 00:02:33 PDT --- Created an attachment (id=38088) View: https://bugs.freedesktop.org/attachment.cgi?id=38088 Review: https://bugs.freedesktop.org/review?bug=29575attachment=38088 possible fix Does this kernel patch fix kms? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 6/6] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM
This reduces the cost of software fallback in
https://bugs.freedesktop.org/show_bug.cgi?id=27139
It changes video rate from 2 seconds per frame with 100% CPU in
Xorg to something close to 24 fps with 40% CPU in Xorg. (Of
course, CPU usage drops to 10% when Firefox uses RepeatPad, but
this patch is useful so that fallback is not so punishing.) ATI
Mobility Radeon X1400 (ChipID = 0x7145)
AFAIK migrating the BO from VRAM to GTT in PrepareAccess doesn't
seem to be a good idea without more information. Only EXA really
knows whether a read is necessary, and only EXA knows which
portions of the pixmap will be read, so DownloadFromScreen when
EXA knows it is necessary seems the best solution. (EXA doesn't
always get this right but that's how things are meant to work and
usually it gets there in the end.)
Perhaps something else to consider in the future is moving the
BO from VRAM to GTT in DFS, but that also has pros and cons.
This approach seems to work well enough so far.
In this patch, RADEONPrepareAccess_CS still proceeds if it knows
that the BO is not going to be in VRAM. EXA will release its
system memory copy, so that there is only one copy in system
memory.
(Maybe, in some ways, it might be better to fail so that EXA can
keep a copy and won't have to refetch if the BO gets moved to
VRAM, but it seems pointless to keep around two copies in system
memory and memcpy between them for GPU reads.)
I wondered whether PrepareAccess could fail for the visible screen
with mixed pixmaps as suggested here
http://www.mentby.com/maarten-maathuis/exa-classic-problem-with-xv.html
When I tried that, however, I ended up with pixels in the wrong
places, a bit like what I would expect if the pitch were wrong.
From 70542f5e1e2b255c06e3b92a70cbedecfa711132 Mon Sep 17 00: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 operations.
https://bugs.freedesktop.org/show_bug.cgi?id=27139
---
src/radeon_exa.c | 36 +---
1 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index bf7cb88..c0f9dc9 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -284,12 +284,21 @@ Bool RADEONPrepareAccess_CS(PixmapPtr pPix, int index)
ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
RADEONInfoPtr info = RADEONPTR(pScrn);
struct radeon_exa_pixmap_priv *driver_priv;
+uint32_t possible_domains = ~0U;
+uint32_t current_domain = 0;
+#ifdef EXA_MIXED_PIXMAPS
+Bool can_fail = !(pPix-drawable.bitsPerPixel 8)
+ pPix != pScreen-GetScreenPixmap(pScreen)
+(info-accel_state-exa-flags EXA_MIXED_PIXMAPS);
+#else
+Bool can_fail = FALSE;
+#endif
+Bool flush = FALSE;
int ret;
#if X_BYTE_ORDER == X_BIG_ENDIAN
/* May need to handle byte swapping in DownloadFrom/UploadToScreen */
-if (pPix-drawable.bitsPerPixel 8
- pPix != pScreen-GetScreenPixmap(pScreen))
+if (can_fail pPix-drawable.bitsPerPixel 8)
return FALSE;
#endif
@@ -298,7 +307,28 @@ Bool RADEONPrepareAccess_CS(PixmapPtr pPix, int index)
return FALSE;
/* if we have more refs than just the BO then flush */
-if (radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs))
+if (radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)) {
+ flush = TRUE;
+
+ if (can_fail) {
+ possible_domains = radeon_bo_get_src_domain(driver_priv-bo);
+ if (possible_domains == RADEON_GEM_DOMAIN_VRAM)
+ return FALSE; /* use DownloadFromScreen */
+ }
+}
+
+/* if the BO might end up in VRAM, prefer DownloadFromScreen */
+if (can_fail (possible_domains RADEON_GEM_DOMAIN_VRAM)) {
+ radeon_bo_is_busy(driver_priv-bo, current_domain);
+
+ if (current_domain possible_domains) {
+ if (current_domain == RADEON_GEM_DOMAIN_VRAM)
+ return FALSE;
+ } else if (possible_domains RADEON_GEM_DOMAIN_VRAM)
+ return FALSE;
+}
+
+if (flush)
radeon_cs_flush_indirect(pScrn);
/* flush IB */
--
1.7.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/6] DownloadFromScreenCS: download via a scratch BO if pixmap domain is unknown
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 the domain out-parameter.
If this happens, then download via a scratch GTT BO to avoid CPU VRAM read.
---
src/r600_exa.c |2 +-
src/radeon_exa_funcs.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/r600_exa.c b/src/r600_exa.c
index d6e98ff..9b7a0c9 100644
--- a/src/r600_exa.c
+++ b/src/r600_exa.c
@@ -1885,7 +1885,7 @@ R600DownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
if (!src_domain)
radeon_bo_is_busy(driver_priv-bo, src_domain);
-if (src_domain != RADEON_GEM_DOMAIN_VRAM)
+if (src_domain ~(uint32_t)RADEON_GEM_DOMAIN_VRAM)
return FALSE;
size = scratch_pitch * h;
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index 2df6ccb..a82e416 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -598,7 +598,7 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
if (!src_domain)
radeon_bo_is_busy(driver_priv-bo, src_domain);
-if (src_domain != RADEON_GEM_DOMAIN_VRAM) {
+if (src_domain ~(uint32_t)RADEON_GEM_DOMAIN_VRAM) {
#if X_BYTE_ORDER == X_BIG_ENDIAN
/* Can't return FALSE here if we need to swap bytes */
if (swap != RADEON_HOST_DATA_SWAP_NONE) {
--
1.7.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 3/6] RADEONDownloadFromScreenCS: flush CS writes before mapping BO for read
(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
If unflushed CS operations write to the pixmap BO, then these need to be
flushed before mapping the BO for read. This currently only affects big
endian systems and only when the operation writes to the GTT domain.
---
src/radeon_exa_funcs.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index a82e416..d02c787 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -567,6 +567,9 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
unsigned bpp = pSrc-drawable.bitsPerPixel;
uint32_t scratch_pitch = RADEON_ALIGN(w * bpp / 8, 64);
uint32_t swap = RADEON_HOST_DATA_SWAP_NONE;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+Bool flush = FALSE;
+#endif
Bool r;
if (bpp 8)
@@ -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 == X_BIG_ENDIAN
+ else /* A write may be scheduled */
+ flush = TRUE;
+#endif
}
if (!src_domain)
@@ -631,11 +638,14 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y,
int w,
scratch_pitch 16, x, y, 0, 0, w, h,
RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT,
RADEON_GEM_DOMAIN_GTT);
-FLUSH_RING();
-
#if X_BYTE_ORDER == X_BIG_ENDIAN
+flush = TRUE;
+
copy:
+if (flush)
#endif
+ FLUSH_RING();
+
r = radeon_bo_map(scratch, 0);
if (r) {
r = FALSE;
--
1.7.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 4/6] radeon: complete big endian UTS and DFS even when scratch allocation fails
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 byte-swapping is required
so UploadToScreen and DownloadFromScreen cannot rely on fallback to
PrepareAccess.
When scratch BO space allocation fails, this patch merely adds simple fallback
to direct CPU access without any GPU blit. This sometimes requires a CS flush
even in UploadToScreen. (No allocation retry after a flush is added here.)
---
src/radeon_exa_funcs.c | 120 +--
1 files changed, 84 insertions(+), 36 deletions(-)
diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
index d02c787..8c9a874 100644
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -459,7 +459,8 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int w, int h,
ScreenPtr pScreen = pDst-drawable.pScreen;
RINFO_FROM_SCREEN(pScreen);
struct radeon_exa_pixmap_priv *driver_priv;
-struct radeon_bo *scratch;
+struct radeon_bo *scratch = NULL;
+struct radeon_bo *copy_dst;
unsigned char *dst;
unsigned size;
uint32_t datatype = 0;
@@ -467,7 +468,12 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int w, int h,
uint32_t dst_pitch_offset;
unsigned bpp = pDst-drawable.bitsPerPixel;
uint32_t scratch_pitch = RADEON_ALIGN(w * bpp / 8, 64);
+uint32_t copy_pitch;
uint32_t swap = RADEON_HOST_DATA_SWAP_NONE;
+int ret;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+Bool flush = TRUE;
+#endif
Bool r;
int i;
@@ -490,54 +496,78 @@ RADEONUploadToScreenCS(PixmapPtr pDst, int x, int y, int w, int h,
#endif
/* If we know the BO won't be busy, don't bother */
-if (!radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)
- !radeon_bo_is_busy(driver_priv-bo, dst_domain)) {
#if X_BYTE_ORDER == X_BIG_ENDIAN
- /* Can't return FALSE here if we need to swap bytes */
- if (swap != RADEON_HOST_DATA_SWAP_NONE
- driver_priv-bo != info-front_bo) {
- scratch = driver_priv-bo;
- scratch_pitch = pDst-devKind;
- goto copy;
- }
+copy_dst = driver_priv-bo;
+copy_pitch = pSrc-devKind;
#endif
- return FALSE;
+if (!radeon_bo_is_referenced_by_cs(driver_priv-bo, info-cs)) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ flush = FALSE;
+#endif
+ if (!radeon_bo_is_busy(driver_priv-bo, dst_domain)) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ /* Can't return FALSE here if we need to swap bytes */
+ if (swap != RADEON_HOST_DATA_SWAP_NONE
+ driver_priv-bo != info-front_bo) {
+ goto copy;
+ }
+#endif
+ return FALSE;
+ }
}
size = scratch_pitch * h;
scratch = radeon_bo_open(info-bufmgr, 0, size, 0, RADEON_GEM_DOMAIN_GTT, 0);
if (scratch == NULL) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ if (swap != RADEON_HOST_DATA_SWAP_NONE
+ driver_priv-bo != info-front_bo) {
+ goto copy;
+ }
+#endif
return FALSE;
}
radeon_cs_space_reset_bos(info-cs);
radeon_add_pixmap(info-cs, pDst, 0, RADEON_GEM_DOMAIN_VRAM);
radeon_cs_space_add_persistent_bo(info-cs, scratch, RADEON_GEM_DOMAIN_GTT, 0);
-r = radeon_cs_space_check(info-cs);
-if (r) {
+ret = radeon_cs_space_check(info-cs);
+if (ret) {
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ if (swap != RADEON_HOST_DATA_SWAP_NONE
+ driver_priv-bo != info-front_bo) {
+ goto copy;
+ }
+#endif
r = FALSE;
goto out;
}
-
+copy_dst = scratch;
+copy_pitch = scratch_pitch;
#if X_BYTE_ORDER == X_BIG_ENDIAN
+flush = FALSE;
+
copy:
+if (flush)
+ radeon_cs_flush_indirect(pScrn);
#endif
-r = radeon_bo_map(scratch, 0);
-if (r) {
+
+ret = radeon_bo_map(copy_dst, 0);
+if (ret) {
r = FALSE;
goto out;
}
r = TRUE;
size = w * bpp / 8;
-dst = scratch-ptr;
-if (scratch == driver_priv-bo)
- dst += y * scratch_pitch + x * bpp / 8;
+dst = copy_dst-ptr;
+if (copy_dst == driver_priv-bo)
+ dst += y * copy_pitch + x * bpp / 8;
for (i = 0; i h; i++) {
-RADEONCopySwap(dst + i * scratch_pitch, (uint8_t*)src, size, swap);
+RADEONCopySwap(dst + i * copy_pitch, (uint8_t*)src, size, swap);
src += src_pitch;
}
-radeon_bo_unmap(scratch);
+radeon_bo_unmap(copy_dst);
-if (scratch != driver_priv-bo) {
+if (copy_dst == scratch) {
RADEONGetDatatypeBpp(pDst-drawable.bitsPerPixel, datatype);
RADEONGetPixmapOffsetPitch(pDst, dst_pitch_offset);
ACCEL_PREAMBLE();
@@ -548,7 +578,7 @@ copy:
}
out:
-if (scratch != driver_priv-bo)
+if (scratch)
radeon_bo_unref(scratch);
return r;
}
@@ -559,14 +589,17 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y, int w,
{
RINFO_FROM_SCREEN(pSrc-drawable.pScreen);
struct radeon_exa_pixmap_priv *driver_priv;
-struct
[Bug 27139] html5 ogg video playback in firefox unusable
https://bugs.freedesktop.org/show_bug.cgi?id=27139 --- Comment #23 from Karl Tomlinson bugs.freedesk...@karlt.net 2010-08-23 00:53:10 PDT --- (In reply to comment #20) The patch seems to contain some good ideas but to try to do too many things at once. Please post it to the xorg-driver-ati mailing list directly using git send-email (or at least generated by git format-patch) for easier review and discussion. I broke the patch up and touched up a couple of things. Apologies for the resend of patches with bad headers due to my own failure. If someone knows any secrets to make lists.x.org archive more than the first part of multipart messages, please let me know. Unfortunately I don't know of anywhere where the attachments are archived. I guess I can configure git send-email if necessary. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
0 A.D bug with radeon driver
hello,
i am a fedora packager and i have a problem with radeon driver not
fglrx for this game http://www.wildfiregames.com/0ad
i do a package:
* 32:
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415656name=0ad-data-r07970-1.20100819svn8004.fc13.noarch.rpm
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415656name=0ad-r07970-1.20100819svn8004.fc13.i686.rpm
* 64:
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415655name=0ad-data-r07970-1.20100819svn8004.fc13.noarch.rpm
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415655name=0ad-r07970-1.20100819svn8004.fc13.x86_64.rpm
log error:
___
(gdb) bt full
#0 0x7fffe9926e99 in next_ins (pAsm=0x2a3ff70) at
r700_assembler.c:2619
pILInst = value optimized out
#1 0x7fffe992776c in assemble_MOV (pAsm=0x2a3ff70) at
r700_assembler.c:3874
No locals.
#2 0x7fffe992b594 in AssembleInstr (uiFirstInst=value optimized
out, uiIL_Shift=0, uiNumberInsts=4, pILInst=0x2a41e30,
pR700AsmCode=0x2a3ff70) at r700_assembler.c:5622
i = 1
#3 0x7fffe992c7fd in r700TranslateFragmentShader (fp=0x2a3bcc0,
mesa_fp=0x2a3bcc0, ctx=0xb493f0) at r700_fragprog.c:412
number_of_colors_exported = value optimized out
z_enabled = 0 '\000'
unBit = value optimized out
shadow_unit = value optimized out
i = value optimized out
inst = value optimized out
shadow_ambient = {STATE_INTERNAL, STATE_SHADOW_AMBIENT, 0, 0, 0}
#4 0x7fffe99360af in r700UpdateShaders (ctx=0xb493f0) at
r700_state.c:72
context = 0xb454f0
#5 0x7fffe9938953 in r700TryDrawPrims (ctx=0xb493f0,
arrays=0xb988b8, prim=0x7fffdba0, nr_prims=1, ib=0x7fffdb80,
index_bounds_valid=value optimized out, min_index=0, max_index=75)
at r700_render.c:904
context = 0xb454f0
i = value optimized out
radeon = 0xb454f0
rrb = value optimized out
emit_end = value optimized out
id = 0
#6 r700DrawPrims (ctx=0xb493f0, arrays=0xb988b8, prim=0x7fffdba0,
nr_prims=1, ib=0x7fffdb80, index_bounds_valid=value optimized out,
min_index=0, max_index=75) at r700_render.c:993
retval = 0 '\000'
#7 0x7fffe99c1e05 in vbo_validated_drawrangeelements (ctx=0xb493f0,
mode=4, index_bounds_valid=1 '\001', start=0, end=75, count=138,
type=5123, indices=0x29f1450, basevertex=0)
at vbo/vbo_exec_array.c:663
vbo = 0xb95c40
exec = 0xb96860
ib = {count = 138, type = 5123, obj = 0xafb500, ptr = 0x29f1450}
prim = {{mode = 4, indexed = 1, begin = 1, end = 1, weak = 0,
pad = 0, start = 0, count = 138, basevertex = 0}}
#8 0x7fffe99c2086 in vbo_exec_DrawRangeElementsBaseVertex (mode=4,
start=0, end=75, count=138, type=5123, indices=0x29f1450, basevertex=0)
at vbo/vbo_exec_array.c:771
warnCount = 0
ctx = 0xb493f0
__PRETTY_FUNCTION__ = vbo_exec_DrawRangeElementsBaseVertex
#9 0x7fffe99c20f0 in vbo_exec_DrawRangeElements (mode=value
optimized out, start=value optimized out, end=value optimized out,
count=value optimized out, type=value optimized out,
indices=value optimized out) at vbo/vbo_exec_array.c:788
No locals.
#10 0x00559d2d in FixedFunctionModelRenderer::RenderModel
(this=0xf02d80, streamflags=value optimized out, model=value
optimized out, data=value optimized out)
at ../../../source/renderer/FixedFunctionModelRenderer.cpp:290
mdldef = {px = 0x20d9f70, pn = {pi_ = 0x20da460}}
ffmodel = value optimized out
numFaces = 46
base = 0x474e0 Address 0x474e0 out of bounds
stride = 16
#11 0x00568b38 in SortModelRenderer::Render (this=0xf01ff0,
modifier=..., flags=1)
at ../../../source/renderer/TransparencyRenderer.cpp:576
tex = 0x20efdf0
smdl = 0x29f13a0
mdl = 0x20efd30
mdef = {px = 0x20d9f70, pn = {pi_ = 0x20da460}}
it =
streamflags = 9
texturematrix = value optimized out
---Type return to continue, or q return to quit---
lastmdef = {px = 0x20d9f70, pn = {pi_ = 0x20da460}}
lasttex = 0x20efdf0
pass = 0
__func__ = Render
#12 0x0054d230 in CRenderer::RenderShadowMap (this=0xe9ffb0)
at ../../../source/renderer/Renderer.cpp:858
__profile = {static evMap = optimized out}
shadowTransp = value optimized out
transparentShadows = {px = 0xf07bf0, pn = {pi_ = 0xf07c10}}
#13 0x0054d754 in CRenderer::RenderSubmissions (this=0xe9ffb0)
at ../../../source/renderer/Renderer.cpp:1223
No locals.
#14 0x0054d834 in CRenderer::RenderScene (this=0xe9ffb0,
scene=0x1418e20) at ../../../source/renderer/Renderer.cpp:1450
frustum = {m_aPlanes = {{m_Norm = {X = -3.43084455, Y = -0.5, Z
= 0.866025448}, m_Dist = 204.526093}, {m_Norm = {X = 3.43084455, Y =
-0.5, Z = 0.866025448}, m_Dist = -669.317993}, {m_Norm = {X = 0,
Y = 3.25116825, Z = 3.03176332}, m_Dist =
[PATCH] xv: fix non-kms/non-dri Xv column ordering on big endian systems
Column order is wrong on big endian systems, primarly because of a
bits / bytes mix up with the bpp variable. Fix tested with r100 and
r300, screen depth 16 and 32 with YV12 and YUY2 (overlay, textured video),
RGBA and RGBT (overlay).
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=29041
Signed-off-by: Heikki Lindholm ho...@iki.fi
---
src/radeon_video.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/radeon_video.c b/src/radeon_video.c
index dc75279..1a42951 100644
--- a/src/radeon_video.c
+++ b/src/radeon_video.c
@@ -2216,11 +2216,15 @@ RADEONCopyData(
swap = RADEON_HOST_DATA_SWAP_32BIT;
break;
}
- } else if (bpp != pScrn-bitsPerPixel) {
- if (bpp == 8)
+ } else {
+ switch (pScrn-bitsPerPixel) {
+ case 16:
+ swap = RADEON_HOST_DATA_SWAP_16BIT;
+ break;
+ case 32:
swap = RADEON_HOST_DATA_SWAP_32BIT;
- else
- swap = RADEON_HOST_DATA_SWAP_HDW;
+ break;
+ }
}
#endif
--
1.7.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: evergreen acceleration support
On 08/23/2010 01:38 AM, Dave Witbrodt wrote:
On 08/20/2010 05:21 PM, Alex Deucher wrote:
I've just pushed out the initial evergreen (radeon HD5xxx)
acceleration support for EXA and Xv to the evergreen_accel branch of
xf86-video-ati. Full support for EXA and Xv is available. To use it,
you'll need 2.6.35 with kms enabled. There are still some GPU hangs
in some cases that we haven't sorted out yet. Richard will be pushing
out mesa support as soon as he finishes rebasing his tree against mesa
master. We'll be releasing updated register specs eventually, but as
you can see, most of the registers and bit fields are the same as
r6xx/r7xx. Happy Hacking!
Alex
Crashes for me when the boot scripts start 'xdm'. Attached tarball has
'dmesg' output, copy of 'Xorg.0.log', and copy of 'xdm.log' (with same
backtrace as Xorg.0.log).
Should I put this on Bugzilla, or is evergreen-accel too new?
Hardware:
Radeon HD 5750
Software:
linux 2.6.35.2
[merged with drm-radeon-testing merged up to c9f9e91; have also reverted
5b1714d, and added patch to fix pink vert. line -- not sure if there are
git commits available yet]
libdrm 2.4.21
mesa 7.9-devel, git be99100
Hmm, I was just looking over the build log for Mesa that I saved. Not sure
if this has to do with the crash, but when I followed the warnings to the
code, this looks potentially disastrous:
r600_cmdbuf.h:201:63: warning: backslash and newline separated by space
r600_cmdbuf.h:202:79: warning: backslash and newline separated by space
Here are the offending lines:
/* evergreen */
#define EVERGREEN_OUT_BATCH_REGS(reg, num) \
do {\
if ((reg) = R600_SET_CONFIG_REG_OFFSET (reg)
R600_SET_CONFIG_REG_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_CONFIG_REG, (num)));
\
R600_OUT_BATCH(((reg) - R600_SET_CONFIG_REG_OFFSET) 2);
\
} else if ((reg) = R600_SET_CONTEXT_REG_OFFSET (reg)
R600_SET_CONTEXT_REG_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_CONTEXT_REG, (num)));
\
* R600_OUT_BATCH(((reg) - R600_SET_CONTEXT_REG_OFFSET) 2);
\
* } else if ((reg) = EG_SET_RESOURCE_OFFSET (reg)
EG_SET_RESOURCE_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_RESOURCE, (num)));
\
R600_OUT_BATCH(((reg) - EG_SET_RESOURCE_OFFSET) 2); \
} else if ((reg) = EG_SET_LOOP_CONST_OFFSET (reg)
EG_SET_LOOP_CONST_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_LOOP_CONST, (num)));
\
R600_OUT_BATCH(((reg) - EG_SET_LOOP_CONST_OFFSET) 2);
\
} else if ((reg) = R600_SET_SAMPLER_OFFSET (reg)
R600_SET_SAMPLER_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_SAMPLER, (num))); \
R600_OUT_BATCH(((reg) - R600_SET_SAMPLER_OFFSET) 2); \
} else if ((reg) = R600_SET_CTL_CONST_OFFSET (reg)
R600_SET_CTL_CONST_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_CTL_CONST, (num)));
\
R600_OUT_BATCH(((reg) - R600_SET_CTL_CONST_OFFSET) 2);
\
} else if ((reg) = EG_SET_BOOL_CONST_OFFSET (reg)
EG_SET_BOOL_CONST_END) { \
R600_OUT_BATCH(CP_PACKET3(R600_IT_SET_BOOL_CONST, (num)));
\
R600_OUT_BATCH(((reg) - EG_SET_BOOL_CONST_OFFSET) 2);
\
} else {\
R600_OUT_BATCH(CP_PACKET0((reg), (num))); \
} \
} while (0)
Looks like a bad place for escaped newlines to fail, but if this was
really the problem, wouldn't the compilation have failed instead?
Dave W.
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: evergreen acceleration support
On 08/23/2010 01:38 AM, Dave Witbrodt wrote: On 08/20/2010 05:21 PM, Alex Deucher wrote: I've just pushed out the initial evergreen (radeon HD5xxx) acceleration support for EXA and Xv to the evergreen_accel branch of xf86-video-ati. Full support for EXA and Xv is available. To use it, you'll need 2.6.35 with kms enabled. There are still some GPU hangs in some cases that we haven't sorted out yet. Richard will be pushing out mesa support as soon as he finishes rebasing his tree against mesa master. We'll be releasing updated register specs eventually, but as you can see, most of the registers and bit fields are the same as r6xx/r7xx. Happy Hacking! Alex Crashes for me when the boot scripts start 'xdm'. Attached tarball has 'dmesg' output, copy of 'Xorg.0.log', and copy of 'xdm.log' (with same backtrace as Xorg.0.log). Should I put this on Bugzilla, or is evergreen-accel too new? Hardware: Radeon HD 5750 Software: linux 2.6.35.2 [merged with drm-radeon-testing merged up to c9f9e91; have also reverted 5b1714d, and added patch to fix pink vert. line -- not sure if there are git commits available yet] libdrm 2.4.21 mesa 7.9-devel, git be99100 xorg-server 1.9.0 xf86-video-radeon 6.13.99, branch evergreen-accel (bdd41fec) Note: libdrm was built against a previous kernel; I can rebuild it tomorrow if this is a likely cause of the crash. Except for this handful of packages I rebuild myself, I am using Debian unstable/experimental. Many of the packages are provided with *-dbg versions, but 'xdm' is not one of those. Possibly I could attempt to rebuild an unstripped version of 'xdm' myself; I certainly can install debug versions of xorg-server and radeon, but will the backtrace alone make use of the debugging symbols? I'm not quite sure how I can use 'gdb' in a situation like this to get a better backtrace, but if there's a way I'd be glad to try. New steps: - rebuilt libdrm against current kernel - rebuilt mesa, correcting the warnings about whitespace between backslashes and newlines - rebuilt xorg-server - rebuilt radeon DDX Results: Still crashes as before. Apparently old libdrm was OK. I didn't think Mesa was at fault either: I doubt 'xdm' does much 3D work! ;-) Installing debugging symbols for the X server and the radeon driver prevented the backtrace from showing up at all, for some reason. At the moment, I don't know how to use 'gdb' to get a better backtrace. Is that even possible? Dave W. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: evergreen acceleration support
On Mon, Aug 23, 2010 at 10:19 AM, Dave Witbrodt dawit...@sbcglobal.net wrote: On 08/23/2010 01:38 AM, Dave Witbrodt wrote: On 08/20/2010 05:21 PM, Alex Deucher wrote: I've just pushed out the initial evergreen (radeon HD5xxx) acceleration support for EXA and Xv to the evergreen_accel branch of xf86-video-ati. Full support for EXA and Xv is available. To use it, you'll need 2.6.35 with kms enabled. There are still some GPU hangs in some cases that we haven't sorted out yet. Richard will be pushing out mesa support as soon as he finishes rebasing his tree against mesa master. We'll be releasing updated register specs eventually, but as you can see, most of the registers and bit fields are the same as r6xx/r7xx. Happy Hacking! Alex Crashes for me when the boot scripts start 'xdm'. Attached tarball has 'dmesg' output, copy of 'Xorg.0.log', and copy of 'xdm.log' (with same backtrace as Xorg.0.log). Should I put this on Bugzilla, or is evergreen-accel too new? Hardware: Radeon HD 5750 Software: linux 2.6.35.2 [merged with drm-radeon-testing merged up to c9f9e91; have also reverted 5b1714d, and added patch to fix pink vert. line -- not sure if there are git commits available yet] libdrm 2.4.21 mesa 7.9-devel, git be99100 xorg-server 1.9.0 xf86-video-radeon 6.13.99, branch evergreen-accel (bdd41fec) Note: libdrm was built against a previous kernel; I can rebuild it tomorrow if this is a likely cause of the crash. Except for this handful of packages I rebuild myself, I am using Debian unstable/experimental. Many of the packages are provided with *-dbg versions, but 'xdm' is not one of those. Possibly I could attempt to rebuild an unstripped version of 'xdm' myself; I certainly can install debug versions of xorg-server and radeon, but will the backtrace alone make use of the debugging symbols? I'm not quite sure how I can use 'gdb' in a situation like this to get a better backtrace, but if there's a way I'd be glad to try. New steps: - rebuilt libdrm against current kernel - rebuilt mesa, correcting the warnings about whitespace between backslashes and newlines - rebuilt xorg-server - rebuilt radeon DDX Results: Still crashes as before. Apparently old libdrm was OK. I didn't think Mesa was at fault either: I doubt 'xdm' does much 3D work! ;-) Installing debugging symbols for the X server and the radeon driver prevented the backtrace from showing up at all, for some reason. At the moment, I don't know how to use 'gdb' to get a better backtrace. Is that even possible? It's not a crash per se, it's a gpu lockup. Pretty much every evergreen card is doing this at the moment until I sort out what's causing it. Alex ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: 0 A.D bug with radeon driver
On Fri, Aug 20, 2010 at 8:24 PM, Jonathan MERCIER
jonathan.mercier...@gmail.com wrote:
hello,
i am a fedora packager and i have a problem with radeon driver not
fglrx for this game http://www.wildfiregames.com/0ad
Please file a bug:
https://bugs.freedesktop.org
And attach your xorg log, dmesg and the backtrace.
Alex
i do a package:
* 32:
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415656name=0ad-data-r07970-1.20100819svn8004.fc13.noarch.rpm
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415656name=0ad-r07970-1.20100819svn8004.fc13.i686.rpm
* 64:
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415655name=0ad-data-r07970-1.20100819svn8004.fc13.noarch.rpm
-
http://koji.fedoraproject.org/koji/getfile?taskID=2415655name=0ad-r07970-1.20100819svn8004.fc13.x86_64.rpm
log error:
___
(gdb) bt full
#0 0x7fffe9926e99 in next_ins (pAsm=0x2a3ff70) at
r700_assembler.c:2619
pILInst = value optimized out
#1 0x7fffe992776c in assemble_MOV (pAsm=0x2a3ff70) at
r700_assembler.c:3874
No locals.
#2 0x7fffe992b594 in AssembleInstr (uiFirstInst=value optimized
out, uiIL_Shift=0, uiNumberInsts=4, pILInst=0x2a41e30,
pR700AsmCode=0x2a3ff70) at r700_assembler.c:5622
i = 1
#3 0x7fffe992c7fd in r700TranslateFragmentShader (fp=0x2a3bcc0,
mesa_fp=0x2a3bcc0, ctx=0xb493f0) at r700_fragprog.c:412
number_of_colors_exported = value optimized out
z_enabled = 0 '\000'
unBit = value optimized out
shadow_unit = value optimized out
i = value optimized out
inst = value optimized out
shadow_ambient = {STATE_INTERNAL, STATE_SHADOW_AMBIENT, 0, 0, 0}
#4 0x7fffe99360af in r700UpdateShaders (ctx=0xb493f0) at
r700_state.c:72
context = 0xb454f0
#5 0x7fffe9938953 in r700TryDrawPrims (ctx=0xb493f0,
arrays=0xb988b8, prim=0x7fffdba0, nr_prims=1, ib=0x7fffdb80,
index_bounds_valid=value optimized out, min_index=0, max_index=75)
at r700_render.c:904
context = 0xb454f0
i = value optimized out
radeon = 0xb454f0
rrb = value optimized out
emit_end = value optimized out
id = 0
#6 r700DrawPrims (ctx=0xb493f0, arrays=0xb988b8, prim=0x7fffdba0,
nr_prims=1, ib=0x7fffdb80, index_bounds_valid=value optimized out,
min_index=0, max_index=75) at r700_render.c:993
retval = 0 '\000'
#7 0x7fffe99c1e05 in vbo_validated_drawrangeelements (ctx=0xb493f0,
mode=4, index_bounds_valid=1 '\001', start=0, end=75, count=138,
type=5123, indices=0x29f1450, basevertex=0)
at vbo/vbo_exec_array.c:663
vbo = 0xb95c40
exec = 0xb96860
ib = {count = 138, type = 5123, obj = 0xafb500, ptr = 0x29f1450}
prim = {{mode = 4, indexed = 1, begin = 1, end = 1, weak = 0,
pad = 0, start = 0, count = 138, basevertex = 0}}
#8 0x7fffe99c2086 in vbo_exec_DrawRangeElementsBaseVertex (mode=4,
start=0, end=75, count=138, type=5123, indices=0x29f1450, basevertex=0)
at vbo/vbo_exec_array.c:771
warnCount = 0
ctx = 0xb493f0
__PRETTY_FUNCTION__ = vbo_exec_DrawRangeElementsBaseVertex
#9 0x7fffe99c20f0 in vbo_exec_DrawRangeElements (mode=value
optimized out, start=value optimized out, end=value optimized out,
count=value optimized out, type=value optimized out,
indices=value optimized out) at vbo/vbo_exec_array.c:788
No locals.
#10 0x00559d2d in FixedFunctionModelRenderer::RenderModel
(this=0xf02d80, streamflags=value optimized out, model=value
optimized out, data=value optimized out)
at ../../../source/renderer/FixedFunctionModelRenderer.cpp:290
mdldef = {px = 0x20d9f70, pn = {pi_ = 0x20da460}}
ffmodel = value optimized out
numFaces = 46
base = 0x474e0 Address 0x474e0 out of bounds
stride = 16
#11 0x00568b38 in SortModelRenderer::Render (this=0xf01ff0,
modifier=..., flags=1)
at ../../../source/renderer/TransparencyRenderer.cpp:576
tex = 0x20efdf0
smdl = 0x29f13a0
mdl = 0x20efd30
mdef = {px = 0x20d9f70, pn = {pi_ = 0x20da460}}
it =
streamflags = 9
texturematrix = value optimized out
---Type return to continue, or q return to quit---
lastmdef = {px = 0x20d9f70, pn = {pi_ = 0x20da460}}
lasttex = 0x20efdf0
pass = 0
__func__ = Render
#12 0x0054d230 in CRenderer::RenderShadowMap (this=0xe9ffb0)
at ../../../source/renderer/Renderer.cpp:858
__profile = {static evMap = optimized out}
shadowTransp = value optimized out
transparentShadows = {px = 0xf07bf0, pn = {pi_ = 0xf07c10}}
#13 0x0054d754 in CRenderer::RenderSubmissions (this=0xe9ffb0)
at ../../../source/renderer/Renderer.cpp:1223
No locals.
#14 0x0054d834 in CRenderer::RenderScene (this=0xe9ffb0,
scene=0x1418e20) at ../../../source/renderer/Renderer.cpp:1450
frustum =
[Bug 29575] My radeon 4570 mobile not work under linux for kms (kernel mode settings)
https://bugs.freedesktop.org/show_bug.cgi?id=29575 --- Comment #10 from BRULE Herman alpha_one_...@first-world.info 2010-08-23 11:41:28 PDT --- Created an attachment (id=38108) -- (https://bugs.freedesktop.org/attachment.cgi?id=38108) dmesg after patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 29575] My radeon 4570 mobile not work under linux for kms (kernel mode settings)
https://bugs.freedesktop.org/show_bug.cgi?id=29575 --- Comment #11 from BRULE Herman alpha_one_...@first-world.info 2010-08-23 11:42:23 PDT --- Same after your patch., see the dmesg after patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 29575] My radeon 4570 mobile not work under linux for kms (kernel mode settings)
https://bugs.freedesktop.org/show_bug.cgi?id=29575 --- Comment #12 from BRULE Herman alpha_one_...@first-world.info 2010-08-23 13:29:37 PDT --- More info: Which this patch I have NO 3D AT ALL when kms is disabled. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
