Re: [patches] Re: r300 radeon 9800 lockup
On Mon, 30 May 2005 20:31:24 -0400 Jonathan Bastien-Filiatrault <[EMAIL PROTECTED]> wrote: > Adam K Kirchhoff wrote: > > > Nicolai Haehnle wrote: > > > >> Hi everybody, > >> > >> I once again tripped upon an R300 lockup (possibly the same one that > >> everybody's been talking about) and spent the last one and half days > >> chasing it down. > >> > >> It turns out that writing the vertex buffer age to scratch registers > >> (the ones that are written back to main memory) during a 3D sequence > >> is a bad idea. Apparently, this confuses the memory controller so > >> much that some part of the engine locks up hard. > >> > >> The attached patch.out-of-loop-dispatch-age fixes this, at least for me. > >> > >> The attached patch.remove-userspace-pacifiers removes additional > >> unnecessary emission of the pacifier sequence from the userspace > >> driver. Userspace isn't supposed to emit this sequence anyway. > >> > >> Could everybody please test whether a) the first patch really does > >> fix the lockups people are seeing and > >> b) whether combining both the first and the second patch causes any > >> regressions. > >> > >> If everything's fine with these patches, I'm going to commit them in > >> a few days or so. > >> > >> cu, > >> Nicolai > >> > > > > A) The first patch may help a little, but definitely doesn't eliminate > > the lockups. > > > > B) Huge regression. With both patches I get an immediate lockup when > > launching glxgears (before the > > window is even drawn). > > > > Adam > > > Funny enough, two days ago, I played vegastrike for litterally _hours_ > with my Radeon 9800 Pro, both patches applied, I restarted the game a > couple times and I could not get it to lockup. However, the day after, I > could not even start the game without causing a lockup. Looks like you > did something good, keep up the great work. This is probably my fault if you updated local copy meanwhile. You can enable the old behaviour by commenting line "#define CB_DPATH" of r300_ioctl.c if its there. -- Aapo Tahkola --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Adam K Kirchhoff wrote: > Nicolai Haehnle wrote: > >> Hi everybody, >> >> I once again tripped upon an R300 lockup (possibly the same one that >> everybody's been talking about) and spent the last one and half days >> chasing it down. >> >> It turns out that writing the vertex buffer age to scratch registers >> (the ones that are written back to main memory) during a 3D sequence >> is a bad idea. Apparently, this confuses the memory controller so >> much that some part of the engine locks up hard. >> >> The attached patch.out-of-loop-dispatch-age fixes this, at least for me. >> >> The attached patch.remove-userspace-pacifiers removes additional >> unnecessary emission of the pacifier sequence from the userspace >> driver. Userspace isn't supposed to emit this sequence anyway. >> >> Could everybody please test whether a) the first patch really does >> fix the lockups people are seeing and >> b) whether combining both the first and the second patch causes any >> regressions. >> >> If everything's fine with these patches, I'm going to commit them in >> a few days or so. >> >> cu, >> Nicolai >> > > A) The first patch may help a little, but definitely doesn't eliminate > the lockups. > > B) Huge regression. With both patches I get an immediate lockup when > launching glxgears (before the > window is even drawn). > > Adam > Funny enough, two days ago, I played vegastrike for litterally _hours_ with my Radeon 9800 Pro, both patches applied, I restarted the game a couple times and I could not get it to lockup. However, the day after, I could not even start the game without causing a lockup. Looks like you did something good, keep up the great work. Keep up the good work, I'm sure you guys will figure it out, Jonathan signature.asc Description: OpenPGP digital signature
Re: [patches] Re: r300 radeon 9800 lockup
Nicolai Haehnle wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai A) The first patch may help a little, but definitely doesn't eliminate the lockups. B) Huge regression. With both patches I get an immediate lockup when launching glxgears (before the window is even drawn). Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
On Sunday 29 May 2005 02:31, Ben Skeggs wrote:
> Morning,
>
> After playing UT2004 for 10 or so minutes, and then quickly checking
> some other
> apps known to worn, I see no regressions with either patch.
>
> I'll be putting it through some more rigorous testing as the day
> progresses, will
> report back if I find anything.
>
> Also, out of interest, what triggered the lockup you saw?
Pretty much anything could trigger it, from glxgears (unlikely lockup) over
glean (regular lockups) to cube (almost instant lockup).
Unfortunately, just like others are reporting, I'm still getting lockups,
too. This time, however, they are more elusive as the lockups disappear as
soon as I start looking for them:
I used the attached patch (in variations) to hunt for the previous lockup.
What this patch does is that it basically commits the ring buffer after
every ADVANCE_RING and waits for the read ptr to catch up with the write
ptr. Feel free to try this patch if you're seeing lockups, perhaps you can
find something out that way. However, as soon as I enable the call to
commit_and_wait, the lockups disappear for me.
I'm still going to try to find this thing, but it looks like it's going to
be difficult.
cu,
Nicolai
Index: drm/shared-core/radeon_cp.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_cp.c,v
retrieving revision 1.7
diff -u -3 -p -r1.7 radeon_cp.c
--- drm/shared-core/radeon_cp.c 19 Apr 2005 21:05:18 - 1.7
+++ drm/shared-core/radeon_cp.c 28 May 2005 20:34:04 -
@@ -923,6 +923,56 @@ static int radeon_do_wait_for_idle(drm_r
return DRM_ERR(EBUSY);
}
+
+/* Debugging function:
+ *
+ * Commit the ring immediately and verify that the hardware is making
+ * progress on the ring.
+ */
+static int failed_once = 0;
+static const char* prev_inflight_caller = 0;
+static const char* prev2_inflight_caller = 0;
+static const char* prev3_inflight_caller = 0;
+
+void radeon_do_inflight_commit_and_wait(drm_radeon_private_t * dev_priv, const char* caller)
+{
+ const char* prev3_caller = prev3_inflight_caller;
+ const char* prev2_caller = prev2_inflight_caller;
+ const char* prev_caller = prev_inflight_caller;
+ const char* cur_caller = caller;
+ u32 old_tail = RADEON_READ(RADEON_CP_RB_WPTR);
+ u32 new_tail = dev_priv->ring.tail;
+ int i;
+
+ prev3_inflight_caller = prev2_caller;
+ prev2_inflight_caller = prev_caller;
+ prev_inflight_caller = caller;
+
+ if (failed_once)
+ return;
+
+ COMMIT_RING();
+
+ for(i = 0; i < dev_priv->usec_timeout; i++) {
+ u32 head = GET_RING_HEAD(dev_priv);
+
+ if (new_tail > old_tail) {
+ if (head > old_tail && head <= new_tail)
+return;
+ } else {
+ if (head <= new_tail || head > old_tail)
+return;
+ }
+
+ DRM_UDELAY(1);
+ }
+
+ DRM_ERROR("failed! (caller = %s, prev = %s <- %s <- %s)\n", cur_caller, prev_caller, prev2_caller, prev3_caller);
+ radeon_status(dev_priv);
+ failed_once = 1;
+}
+
+
/*
* CP control, initialization
*/
Index: drm/shared-core/radeon_drv.h
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_drv.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 radeon_drv.h
--- drm/shared-core/radeon_drv.h 3 Mar 2005 04:40:21 - 1.12
+++ drm/shared-core/radeon_drv.h 28 May 2005 20:34:05 -
@@ -985,14 +985,39 @@ do { \
#define RING_LOCALS int write, _nr; unsigned int mask; u32 *ring;
+#define ALIGN_RING() do { \
+ int _nr = 32 - (dev_priv->ring.tail & 31); \
+ int _write; \
+ if (dev_priv->ring.space <= (_nr+1) * sizeof(u32)) { \
+ COMMIT_RING(); \
+ radeon_wait_ring( dev_priv, (_nr+1) * sizeof(u32) ); \
+ }\
+ _write = dev_priv->ring.tail; \
+ if (_write & 1) { \
+ dev_priv->ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv->ring.tail_mask; \
+ _nr--; \
+ }\
+ while( _nr >= 2 ) { \
+ /*dev_priv->ring.start[_write++] = CP_PACKET3( RADEON_CP_NOP, 0 );*/ \
+ /*dev_priv->ring.start[_write++] = CP_PACKET0( 0x1438, 0 );*/ \
+ dev_priv->ring.start[_write++] = RADEON_CP_PACKET2; \
+ dev_priv->ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv->ring.tail_mask; \
+ _nr -= 2; \
+ }\
+ dev_priv->ring.tail = _write; \
+} while (0)
+
#define BEGIN_RING( n ) do { \
+ ALIGN_RING(); /* TEST TEST */ \
if ( RADEON_VERBOSE ) { \
DRM_INFO( "BEGIN_RING( %d ) in %s\n", \
n, __FUNCTION__ );\
}\
- if ( dev_priv->ring.space <= (n) * sizeof(u32) ) { \
+ if ( dev_priv->ring.space <= dev_priv->ring.size/2 /*(n+1) * sizeof(u32)*/ ) { \
COMMIT_RING(); \
- radeon_wait_ring( dev_priv, (n) * sizeof(u32) ); \
+ radeon_wait_ring( dev_priv, dev_priv->ring.size/2/*(n+1) * sizeof(u32)*/ ); \
}\
_nr = n; dev_priv->ring.space -= (n) * sizeof(u32
Re: [patches] Re: r300 radeon 9800 lockup
Peter Zubaj wrote: Hi, First patch helped lot (but there are still lockups). Second - no diffrence with or without. Peter Zubaj Nicolai Haehnle wrote: Same here. All the lockups happen, it just takes them longer. Boris Peterbarg Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Hi, First patch helped lot (but there are still lockups). Second - no diffrence with or without. Peter Zubaj Nicolai Haehnle wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Morning,
After playing UT2004 for 10 or so minutes, and then quickly checking
some other
apps known to worn, I see no regressions with either patch.
I'll be putting it through some more rigorous testing as the day
progresses, will
report back if I find anything.
Also, out of interest, what triggered the lockup you saw?
-Ben.
Nicolai Haehnle wrote:
Hi everybody,
I once again tripped upon an R300 lockup (possibly the same one that
everybody's been talking about) and spent the last one and half days
chasing it down.
It turns out that writing the vertex buffer age to scratch registers (the
ones that are written back to main memory) during a 3D sequence is a bad
idea. Apparently, this confuses the memory controller so much that some
part of the engine locks up hard.
The attached patch.out-of-loop-dispatch-age fixes this, at least for me.
The attached patch.remove-userspace-pacifiers removes additional unnecessary
emission of the pacifier sequence from the userspace driver. Userspace
isn't supposed to emit this sequence anyway.
Could everybody please test whether
a) the first patch really does fix the lockups people are seeing and
b) whether combining both the first and the second patch causes any
regressions.
If everything's fine with these patches, I'm going to commit them in a few
days or so.
cu,
Nicolai
Index: drm/shared-core/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.22
diff -u -3 -p -r1.22 r300_cmdbuf.c
--- drm/shared-core/r300_cmdbuf.c 28 May 2005 05:18:42 - 1.22
+++ drm/shared-core/r300_cmdbuf.c 28 May 2005 20:56:59 -
@@ -487,21 +487,19 @@ static __inline__ void r300_pacify(drm_r
}
+/**
+ * Called by r300_do_cp_cmdbuf to update the internal buffer age and state.
+ * The actual age emit is done by r300_do_cp_cmdbuf, which is why you must
+ * be careful about how this function is called.
+ */
static void r300_discard_buffer(drm_device_t * dev, drm_buf_t * buf)
{
-drm_radeon_private_t *dev_priv = dev->dev_private;
-drm_radeon_buf_priv_t *buf_priv = buf->dev_private;
-RING_LOCALS;
-
-buf_priv->age = ++dev_priv->sarea_priv->last_dispatch;
-
-/* Emit the vertex buffer age */
-BEGIN_RING(2);
-RADEON_DISPATCH_AGE(buf_priv->age);
-ADVANCE_RING();
+ drm_radeon_private_t *dev_priv = dev->dev_private;
+ drm_radeon_buf_priv_t *buf_priv = buf->dev_private;
-buf->pending = 1;
-buf->used = 0;
+ buf_priv->age = dev_priv->sarea_priv->last_dispatch+1;
+ buf->pending = 1;
+ buf->used = 0;
}
@@ -518,6 +516,7 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
drm_radeon_private_t *dev_priv = dev->dev_private;
drm_device_dma_t *dma = dev->dma;
drm_buf_t *buf = NULL;
+ int emit_dispatch_age = 0;
int ret = 0;
DRM_DEBUG("\n");
@@ -608,14 +607,15 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
goto cleanup;
}
- r300_discard_buffer(dev, buf);
+ emit_dispatch_age = 1;
+ r300_discard_buffer(dev, buf);
break;
case R300_CMD_WAIT:
/* simple enough, we can do it here */
DRM_DEBUG("R300_CMD_WAIT\n");
if(header.wait.flags==0)break; /* nothing to do */
-
+
{
RING_LOCALS;
@@ -639,6 +639,24 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
cleanup:
r300_pacify(dev_priv);
+
+ /* We emit the vertex buffer age here, outside the pacifier "brackets"
+* for two reasons:
+* (1) This may coalesce multiple age emissions into a single one and
+* (2) more importantly, some chips lock up hard when scratch registers
+* are written inside the pacifier bracket.
+*/
+ if (emit_dispatch_age) {
+ RING_LOCALS;
+
+ dev_priv->sarea_priv->last_dispatch++;
+
+ /* Emit the vertex buffer age */
+ BEGIN_RING(2);
+ RADEON_DISPATCH_AGE(dev_priv->sarea_priv->last_dispatch);
+ ADVANCE_RING();
+ }
+
COMMIT_RING();
return ret;
Index: r300/r300_render.c
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_render.c,v
retrieving revision 1.87
diff -u -3 -p -r1.87 r300_render.c
--- r300/r300_render.c 19 May 2005 00:03:52 - 1.87
+++ r300/r300_render.c 28 May 2005 20:49:43 -
@@ -489,23 +489,18 @@ static GLboolean r300_run_vb_render(GLco
struct vertex_buffer *VB = &tnl->vb;
Re: [patches] Re: r300 radeon 9800 lockup
On 5/28/05, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I once again tripped upon an R300 lockup (possibly the same one that > everybody's been talking about) and spent the last one and half days > chasing it down. > > It turns out that writing the vertex buffer age to scratch registers (the > ones that are written back to main memory) during a 3D sequence is a bad > idea. Apparently, this confuses the memory controller so much that some > part of the engine locks up hard. > > The attached patch.out-of-loop-dispatch-age fixes this, at least for me. > > The attached patch.remove-userspace-pacifiers removes additional unnecessary > emission of the pacifier sequence from the userspace driver. Userspace > isn't supposed to emit this sequence anyway. > > Could everybody please test whether > a) the first patch really does fix the lockups people are seeing and > b) whether combining both the first and the second patch causes any > regressions. > > If everything's fine with these patches, I'm going to commit them in a few > days or so. Seems you are on the good path :) with the first patch i can play quake3 a little bit more (without it i get a lock within a minute or so). Ut2004 lockup too but at least now i can see the menu... If i apply the second patch it leads me to the past situation, a quick lockup... Jerome Glisse --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patches] Re: r300 radeon 9800 lockup
Hi everybody,
I once again tripped upon an R300 lockup (possibly the same one that
everybody's been talking about) and spent the last one and half days
chasing it down.
It turns out that writing the vertex buffer age to scratch registers (the
ones that are written back to main memory) during a 3D sequence is a bad
idea. Apparently, this confuses the memory controller so much that some
part of the engine locks up hard.
The attached patch.out-of-loop-dispatch-age fixes this, at least for me.
The attached patch.remove-userspace-pacifiers removes additional unnecessary
emission of the pacifier sequence from the userspace driver. Userspace
isn't supposed to emit this sequence anyway.
Could everybody please test whether
a) the first patch really does fix the lockups people are seeing and
b) whether combining both the first and the second patch causes any
regressions.
If everything's fine with these patches, I'm going to commit them in a few
days or so.
cu,
Nicolai
Index: drm/shared-core/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.22
diff -u -3 -p -r1.22 r300_cmdbuf.c
--- drm/shared-core/r300_cmdbuf.c 28 May 2005 05:18:42 - 1.22
+++ drm/shared-core/r300_cmdbuf.c 28 May 2005 20:56:59 -
@@ -487,21 +487,19 @@ static __inline__ void r300_pacify(drm_r
}
+/**
+ * Called by r300_do_cp_cmdbuf to update the internal buffer age and state.
+ * The actual age emit is done by r300_do_cp_cmdbuf, which is why you must
+ * be careful about how this function is called.
+ */
static void r300_discard_buffer(drm_device_t * dev, drm_buf_t * buf)
{
-drm_radeon_private_t *dev_priv = dev->dev_private;
-drm_radeon_buf_priv_t *buf_priv = buf->dev_private;
-RING_LOCALS;
-
-buf_priv->age = ++dev_priv->sarea_priv->last_dispatch;
-
-/* Emit the vertex buffer age */
-BEGIN_RING(2);
-RADEON_DISPATCH_AGE(buf_priv->age);
-ADVANCE_RING();
+ drm_radeon_private_t *dev_priv = dev->dev_private;
+ drm_radeon_buf_priv_t *buf_priv = buf->dev_private;
-buf->pending = 1;
-buf->used = 0;
+ buf_priv->age = dev_priv->sarea_priv->last_dispatch+1;
+ buf->pending = 1;
+ buf->used = 0;
}
@@ -518,6 +516,7 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
drm_radeon_private_t *dev_priv = dev->dev_private;
drm_device_dma_t *dma = dev->dma;
drm_buf_t *buf = NULL;
+ int emit_dispatch_age = 0;
int ret = 0;
DRM_DEBUG("\n");
@@ -608,14 +607,15 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
goto cleanup;
}
- r300_discard_buffer(dev, buf);
+ emit_dispatch_age = 1;
+ r300_discard_buffer(dev, buf);
break;
case R300_CMD_WAIT:
/* simple enough, we can do it here */
DRM_DEBUG("R300_CMD_WAIT\n");
if(header.wait.flags==0)break; /* nothing to do */
-
+
{
RING_LOCALS;
@@ -639,6 +639,24 @@ int r300_do_cp_cmdbuf(drm_device_t* dev,
cleanup:
r300_pacify(dev_priv);
+
+ /* We emit the vertex buffer age here, outside the pacifier "brackets"
+ * for two reasons:
+ * (1) This may coalesce multiple age emissions into a single one and
+ * (2) more importantly, some chips lock up hard when scratch registers
+ * are written inside the pacifier bracket.
+ */
+ if (emit_dispatch_age) {
+ RING_LOCALS;
+
+ dev_priv->sarea_priv->last_dispatch++;
+
+ /* Emit the vertex buffer age */
+ BEGIN_RING(2);
+ RADEON_DISPATCH_AGE(dev_priv->sarea_priv->last_dispatch);
+ ADVANCE_RING();
+ }
+
COMMIT_RING();
return ret;
Index: r300/r300_render.c
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_render.c,v
retrieving revision 1.87
diff -u -3 -p -r1.87 r300_render.c
--- r300/r300_render.c 19 May 2005 00:03:52 - 1.87
+++ r300/r300_render.c 28 May 2005 20:49:43 -
@@ -489,23 +489,18 @@ static GLboolean r300_run_vb_render(GLco
struct vertex_buffer *VB = &tnl->vb;
int i, j;
LOCAL_VARS
-
+
if (RADEON_DEBUG & DEBUG_PRIMS)
fprintf(stderr, "%s\n", __FUNCTION__);
-
+
r300ReleaseArrays(ctx);
r300EmitArrays(ctx, GL_FALSE);
// LOCK_HARDWARE(&(rmesa->radeon));
- reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0);
- e32(0x000a);
-
- reg_start(0x4f18,0);
- e32(0x0003);
r300EmitState(rmesa);
-
+
if(hw_tcl_on) /* FIXME */
r300FlushCmdBuf(rmesa, __FUNCTION__);
@@ -515,16 +510,10 @@ static GLboolean r300_run_vb_render(GLco
GLuint prim = VB->Primitive[i].mode;
GLuint start = VB->Primitive[i].start;
GLuint length = VB->Primitive[i].count;
-
+
r300_render_vb_primitive(rmesa, ctx, start, start + length, prim);
}
- reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0);
- e32(0x000a);
-
- reg_start(0x4f18,0);
- e32(0x0003);
-
// end_3d(PASS_PREFIX_VOID);
/* Flush state - we are done drawing.. */
pgpo4sI9yBTrX.pgp
Description: PGP signature
