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
