Leif Delgass wrote:
>On 7 Sep 2002, Peter Andersson wrote:
>>>>I got my computer back this evening and have downloaded and installed
>>>>the latest mach64-0-0-5 branch. I have tried the DMAMode option, i also
>>>>double checked that the changes i made were used when loading DRM ( i
>>>>checked the XFree86.log) and for safety made a cold restart of the
>>>>computer between changing the option.
>>>>When using "async" I got a X-hang when running glxgears. Although
>>>>usually when i login via telnet it takes really long time since
>>>>glxgears/the x-server hogs all of the cpu. And it still does but logging
>>>>in via telnet works as fast as when i have no processes running.When
>>>>running quake2 i get some minor errors when drawing the textures (or
>>>>perhaps when drawing the polygons but it doesn't look like it could be
>>>>polygons). These errors are just temporary and lasts for less than half
>>>>a second which is why i couldn't include a screenshot.
>>>OK, that's expected, "async" is the same as the last snapshot you tried,
>>>but with frame aging added. So frame aging isn't enough to get this
>>>working, but I didn't expect it would. Is there any difference between
>>>the previous snapshot and this one with "async"?
>>As i remember it i didn't have the texture "errors" before. But on the
>>positive side i have the feeling that the programs run longer before the
>>system "hangs" (read below), but i am not a 100% sure about that. I can
>>also hear on the sound that that the sound is continuing to play on
>>quake2 although it pauses for about ten seconds and then plays for about
>>half a second etc. I can't see any significant changes in the graphics
>>though. To make sure i'll leave the computer on like that tonight and
>>look at tomorrow to see if anything has happened.
>You'll probably end up with a huge system log. ;) If things get really
>slow, but you don't have a total lockup, the card engine is probably
>locking up and being repeatedly reset, with debugging info being dumped to
>the system log each time. Could you try turning on debugging in the drm
>(drm_opts=debug) and getting a /proc/kmsg log? You can kill the app as
>soon as the hang happens. If turning debugging on causes a total lockup,
>try without debugging on and check the system log for messages.
The kmsg is included.
>>>>Now for some good news. When using the "sync" option i can actually run
>>>>glxgears without a complete hang!! :) The rendering/movement of the
>>>>gears is a bit "jerky". They spin for a while then they stand still for
>>>>a while and then starts spinning again etc. But this is a real
>>>>improvement since i haven't been able to run glxgears for a couple of
>>>>months. Rendering textures works great!
>>>So apart from the "jerkiness", all apps are working ok with "sync"?
>>Yes, that's right! I have tried it with quake2, glboom, quake(gl) and
>>blender 3D. Should transparency be working? In quake i get semi
>>transparent squares where there should be smoke. (Did not notice that
>>until just now).
>There is a hardware limitation with mach64 that can cause transparency
>problems with some apps. The GL_MODUATE texture environment does not
>modulate alpha values, so it can cause a texture with that texture
>environment to be opaque against the background instead of being alpha
>blended. This caused opaque smoke in early quake3 releases, but more
>recent point releases have a workaround for mach64. So, if you're talking
>about glquake/quakeforge, it depends on the implementation of the
>renderer. The last time I tried the GL renderer from quakeforge, it was
>really slow because the explosions were triggering a software fallback
>(maybe GL_BLEND texture environment?). Can you take a screenshot? Also,
>which version/port of quake are you using?
I am using quakeforge version 0.5.1, and the screenshot is also included
as you can see.