Re: [r300] VB mode success
On Thursday 17 February 2005 22:34, Rune Petersen wrote: On my system it works on my X800 with no lockups. For now I have only tested with glxgears and q3demo. So I won't be of much help fixing this apart from being a success-vector. Are there any pattern in what systems works with VB? I have an R300 ND (PCI ID 0x4E44), and it doesn't work (i.e. it locks up after some time). Also an observation: With VB mode running glxgears I can get an extra 100 fps by moving the window left. If I move it too much it goes back to the initial fps. This doesn't happen with immediate mode. are there a good reason for this? 14345 frames in 5.0 seconds = 2868.983 FPS 14357 frames in 5.0 seconds = 2871.259 FPS 14332 frames in 5.0 seconds = 2866.250 FPS 14324 frames in 5.0 seconds = 2864.621 FPS move 14837 frames in 5.0 seconds = 2967.306 FPS 14905 frames in 5.0 seconds = 2980.958 FPS 14913 frames in 5.0 seconds = 2982.533 FPS 14897 frames in 5.0 seconds = 2979.251 FPS Huh, that's really weird :) One possible cause (though this is really wild speculation) is that you're outputting debug messages somewhere, and moving the window reduces the volume of debug messages. I also have news regarding the (I hope there's only one) VB lockup. I can launch and exit (on 0x4E44 as stated above) glxgears basically as often as I want, as long as I don't let it run for more than a few seconds. During that timeframe I can even do some things that are (used to be) notoriously lockup-prone, such as dragging windows around. But when I let it run more than a few seconds, it invariably locks up. Now the really interesting thing is that I captured the full libGL debug output from several lock runs, and both the line count and the word count of all the logs is *exactly* the same. The byte counts differ by a very small amount, which appears to be due to some buffer indices being smaller (only one digit vs. two digits) in some cases. So I assume that there is some kind of timebomb, at least on my machine, that reliably and reproducably causes the lockup, most likely when some counter or pointer wraps around. I haven't found the exact cause yet, but I'll look further into it. cu, Nicolai Rune Petersen pgp2hEXpEbynZ.pgp Description: PGP signature
Re: [r300] VB mode success
Nicolai Haehnle wrote: On Thursday 17 February 2005 22:34, Rune Petersen wrote: On my system it works on my X800 with no lockups. For now I have only tested with glxgears and q3demo. So I won't be of much help fixing this apart from being a success-vector. Are there any pattern in what systems works with VB? I have an R300 ND (PCI ID 0x4E44), and it doesn't work (i.e. it locks up after some time). Also an observation: With VB mode running glxgears I can get an extra 100 fps by moving the window left. If I move it too much it goes back to the initial fps. This doesn't happen with immediate mode. are there a good reason for this? 14345 frames in 5.0 seconds = 2868.983 FPS 14357 frames in 5.0 seconds = 2871.259 FPS 14332 frames in 5.0 seconds = 2866.250 FPS 14324 frames in 5.0 seconds = 2864.621 FPS move 14837 frames in 5.0 seconds = 2967.306 FPS 14905 frames in 5.0 seconds = 2980.958 FPS 14913 frames in 5.0 seconds = 2982.533 FPS 14897 frames in 5.0 seconds = 2979.251 FPS Huh, that's really weird :) One possible cause (though this is really wild speculation) is that you're outputting debug messages somewhere, and moving the window reduces the volume of debug messages. I would have thought it might be similar to cache lines in main memory - in some positions you end up dirtying fewer cache lines due to alignment. Keith --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB mode success
Hi,
I tested latest CVS of r300 driver. Card is Rageon 9700Pro (NE).
I tested immediate and VB mode, both of them work ok - no locks (tested
in glxgearx, tuxracer, nehe lesson06) . Even with x11perf -shmput 500 I
can not lock machne.
Some screenshots from enemy territory (VB mode):
http://www.gaya.sk/~pzubaj/scr/et1.jpg
http://www.gaya.sk/~pzubaj/scr/et2.jpg
http://www.gaya.sk/~pzubaj/scr/et3.jpg
http://www.gaya.sk/~pzubaj/scr/et4.jpg
http://www.gaya.sk/~pzubaj/scr/et5.jpg
http://www.gaya.sk/~pzubaj/scr/et6.jpg
I trayed attached patch. With this patch still everything works ok - no
lock.
Then I removed all occurrence of (from r300 driver):
reg_start(0x4f18,0);
e32(0x0003);
Still everything works ok - no lock.
Then I removed every
reg_start(R300_RB3D_DSTCACHE_CTLSTAT,0);
e32(0x000a);
computer immediately lock.
For me looks like (my opinions):
R300_RB3D_DSTCACHE_CTLSTAT is needs to be regural inserted to stream.
Register 0x4f18 is only need at begin and end of 3d drawing.
Peter Zubaj
diff -u o/radeon_cp.c n/radeon_cp.c
--- o/radeon_cp.c 2005-01-02 07:18:39.0 +0100
+++ n/radeon_cp.c 2005-02-18 21:36:51.0 +0100
@@ -984,32 +984,14 @@
RING_LOCALS;
DRM_DEBUG(\n);
- if (IS_FAMILY_R300(dev_priv)) {
- BEGIN_RING( 10 );
-
- OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x0002);
- OUT_RING_REG(0x4F18, 0x0001); /* Z cache? */
-
- /* It seems a delay is needed */
- OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) );
- OUT_RING( 0x0 );
-
- RADEON_PURGE_CACHE();
-
- RADEON_WAIT_UNTIL_IDLE();
-
- ADVANCE_RING();
- } else {
+ BEGIN_RING(6);
- BEGIN_RING(6);
+ RADEON_PURGE_CACHE();
+ RADEON_PURGE_ZCACHE();
+ RADEON_WAIT_UNTIL_IDLE();
- RADEON_PURGE_CACHE();
- RADEON_PURGE_ZCACHE();
- RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
- ADVANCE_RING();
- }
-
COMMIT_RING();
return radeon_do_wait_for_idle(dev_priv);
diff -u o/radeon_state.c n/radeon_state.c
--- o/radeon_state.c 2005-02-13 11:35:54.0 +0100
+++ n/radeon_state.c 2005-02-18 21:38:41.0 +0100
@@ -1021,16 +1021,11 @@
/* Wait for the 3D stream to idle before dispatching the bitblt.
* This will prevent data corruption between the two streams.
*/
- if (IS_FAMILY_R300(dev_priv)) {
- /* Make sure the new caches are flushed */
- radeon_do_cp_idle(dev_priv);
- } else {
- BEGIN_RING(2);
+ BEGIN_RING(2);
- RADEON_WAIT_UNTIL_3D_IDLE();
+ RADEON_WAIT_UNTIL_3D_IDLE();
- ADVANCE_RING();
- }
+ ADVANCE_RING();
for (i = 0; i nbox; i++) {
int x = pbox[i].x1;
@@ -1348,9 +1343,12 @@
*/
if (IS_FAMILY_R300(dev_priv)) {
- BEGIN_RING(10);
-OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x0002);
-OUT_RING_REG(0x4F18, 0x0001); /* Z cache? */
+ /*BEGIN_RING(10);*/
+ BEGIN_RING(8);
+/*OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x0002);
+OUT_RING_REG(0x4F18, 0x0001);*/ /* Z cache? */
+
+ OUT_RING_REG(R300_RB3D_DSTCACHE_CTLSTAT, 0x000A);
/* It seems a delay is needed */
OUT_RING( CP_PACKET3( RADEON_CP_NOP, 0 ) );
[r300] VB mode success
On my system it works on my X800 with no lockups. For now I have only tested with glxgears and q3demo. So I won't be of much help fixing this apart from being a success-vector. Are there any pattern in what systems works with VB? Also an observation: With VB mode running glxgears I can get an extra 100 fps by moving the window left. If I move it too much it goes back to the initial fps. This doesn't happen with immediate mode. are there a good reason for this? 14345 frames in 5.0 seconds = 2868.983 FPS 14357 frames in 5.0 seconds = 2871.259 FPS 14332 frames in 5.0 seconds = 2866.250 FPS 14324 frames in 5.0 seconds = 2864.621 FPS move 14837 frames in 5.0 seconds = 2967.306 FPS 14905 frames in 5.0 seconds = 2980.958 FPS 14913 frames in 5.0 seconds = 2982.533 FPS 14897 frames in 5.0 seconds = 2979.251 FPS Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
