[Bug 1153] [Matrox/G200] Direct-rendering fails with G200 configured under AGPMode 2.

[bugzilla-daemon@freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   
 
https://bugs.freedesktop.org/show_bug.cgi?id=1153        
   




------- Additional Comments From jkanowitz@snet.net  2005-01-09 03:35 -------
Update: 

Fought with this some more, now on FreeBSD 5.3-p1.  mga_hal is removed. 
Installed latest FreeBSD DRI package from /usr/ports/graphics/dri (dri-6.2_1,2);
with 6.7, ended up with DRM showing loaded in Xorg.0.log but glxinfo failing to
show direct rendering enabled for "libGL error: __driCreateScreen() not defined
in mga_dri.so!"  (I apologize for the lack of context here, I didn't keep a full
log, and wasn't expecting to progress to a state where I couldn't reproduce it.)

Threw mga_load="YES" into /boot/loader.conf, rebooted, same results.  For
somewhat obvious reasons, most likely.

Rebuilt and reinstalled the DRI port, "just in case."  Same results.

Gave in and installed xorg-server-6.8.1, xorg-libraries-6.8.1, and
xorg-clients-6.8.1, after backing out their previous counterparts.

glxinfo now displays:
name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x24
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x28
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2c
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x30
display: :0  screen: 0
direct rendering: Yes
...

glxgears produces the same warnings, and renders as a black window, while
displaying a somewhat believable FPS.  At least it doesn't trigger the sort of
horrible frozen-keyboard / 'stuttering mouse' syndrome it used to.  (In those
circumstances, the system would remain alive enough to ssh into, but recovering
the console after killing the server proved consistently impossible.)

Some glx clients actually work!  The xmms-iris plugin is unfazed, but at
incredibly reduced performance (below software rendering) vs. what I used to
achieve with the last XFree86 incarnations that worked.  The Xorg process is
shown eating ~95% CPU time in top.

Paging through xscreensaver's GL hacks produced many black/blank previews, and
one case of 'stuttering' during (when attempting to preview 'MirrorBlob') --
but, to my amazement and relief, the mouse remained responsive, the keyboard
LEDs didn't die, mouse events still registered, and it was generally much more
like still having a fully-functional computer with a working X server than a
paperweight in need of reboot.

I've also discovered the "SpeedMine" and "SpeedWorm" hacks work (presumably more
instances of programs using what visuals *are* supported), taking the Xorg
process up to about 35% CPU in top, and approaching a tolerable FPS, though
still much slower than memory suggests.

Taking a hack that doesn't work (e.g. moebius) and trying to invoke it with
every visual not in the 'unsupported' list produces only more recoverable
stutter and blank windows.  Beyond this, I'm at a loss as to what would be
useful, or how much of this is already known.

I'm going to remove the mga_load from loader.conf for my next boot, and see if
anything improves, but figured I'd report.

---

Somewhat OT for where this has been filed, but improved or more-noticable
documentation of the -need- to install the DRI ports on FreeBSD would be
appreciated, as would some visible notice that drm-kmod is very, very stale and
not intended for human consumption.  (...and that the current 'dri' port is only
intended for 6.8.1, if that's the case beyond mga.)        
   
   
--         
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email       
   
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.