On Sun, 08 Jan 2006 01:33:56 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote: > > On Sat, 07 Jan 2006 23:58:44 +0100 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > > > >>Aapo Tahkola wrote: > >> > >>>>My X800 XT is working fine, the only real problem I have with lockups > >>>>are with Quake 3 and is unrelated. > >>> > >>> > >>>Im a bit dubious your problem not being related as I had some similar > >>>problems with q3. > >>>Could you test if "manytex -size 512 512 -n 100" works? > >>>It should lock immediately if theres some problem as indirect buffers kept > >>>in gart get tampered over by texture uploads. > >>> > >> > >>Looks fine, and no lockup. > > > > > > Alright. Have you been able to reproduce this with any other app? > > Perhaps if it hits in menus it might be able to track it down but I wouldnt > > try it otherwise. > > Also, does it lock always at the same time or is it random? > > > > No only Quake 3. in-game lockups are rare, most happens when loading > maps (might be locking up on the first frame) the worst map is Q3DM0, > which might help track it down. Also r_texturebits "32" vs. > r_texturebits "16" increases the chance of a lockup. Could you try Q3DM0 with this patch applied to r300_render.c ? It should ignore all rendering commands at around time leaving menu. Let me know if you cant reproduce the lock with it. BTW, "killall -15 quake3.x86; xrandr -s 0" might be handy if it doesnt lock... -- Aapo Tahkola
q3_render_ign.patch
Description: Binary data
