Red Hat Bugzilla – Bug 57814
GL(X) apps garbled with Matrox G450 and stock config/drivers
Last modified: 2007-04-18 12:38:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
Apps such as Chromium (evidence in URL provided) and Tuxracer produce
garbled output. glgears (xscreensaver) runs fine. Using all stock (X,
XF86config-4, dri/glx modules, etc.) I have changed the AGP setting (from
1x to 4x) in config and I also tried the .o modules (mga, etc.) from
www.matrox.com to no avail. No noticeable errors that I can see, simply
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run Chromium, Tuxracer or (I assume) any other GL app in X.
Actual Results: Garbled output.
Expected Results: Nice 3d gaming pleasure :)
Created attachment 41310 [details]
Created attachment 41311 [details]
Created attachment 41312 [details]
Created attachment 41313 [details]
I have exactly the same problem with a Matrox G200. Intel 440BX motherboard
(P3-600), stock RedHat 7.2 kernel (2.4.7), XFree86 4.1.0, running AGP 1x, 16bpp,
and a rather standard XFree config. The card worked fine in all previous RedHat
versions. Looks like a problem with mga drm.
Please try the recently released XFree86 4.1.0-15 erratum, and update
the bug report with your latest results. You will need to upgrade
Mesa and also the kernel to our latest release as well.
I have updated the software as told (now have kernel-2.4.9-21, XFree86-4.1.0-15
and Mesa-3.4.2-10), but nothing has changed. I can now provide additional info:
it looks like glx programs cannot use textures. Here's sample output (from
chromium, but Quake 2 is very similar):
Failed to upload texture, sz 2048
Memory heap (nil):
heap == 0
End of memory blocks
(this repeats on and on thousands of times, each time with a different number
after sz). So the only reason gears work is because it doesn't use textures at all.
This seems to me to be a Mesa bug of some kind perhaps. I've reported
it upstream to mesa developers to see if it is a known bug or has been
fixed perhaps. I'll update the report when more info becomes available.
I just upgraded to the XFree86-4.2 in rawhide, and I still see the same thing
described herein. I'm running the Mesa-demos programs, and below is a complete
list of the demos that cause problems:
ray (really bad)
tunnel (really bad)
Does this still occur in RHL 7.3 and/or RHL 8.0? What about rawhide (if
anyone has tried rawhide XFree86)?
The bug is still present in RH 7.3. I don't have 8.0, so cannot comment on that.
I hate to ditch a long ago reported bug report like this, but I'm doing it
for a very good reason, and for that I will explain.
In the scheme of bug report prioritization, video game related bugs get very
low priority, since we don't really market the distribution as a video game
platform. In general, a 3D acceleration related bug, is a bug in XFree86 or
Mesa in general, and they're not usually Red Hat Linux specific. It makes
the most amount of sense to report these types of bugs directly to the DRI
project as they have a great number of developers whom work on DRI, Mesa,
and related code every day, compared to Red Hat which currently has 2
X developers, of whom rarely work with 3D related code ever.
Leaving this bug open without commenting on it, really just leaves it open
to not ever get investigated like it really deserves to be since there are
almost always likely to be higher priority bug reports open that keep these
type of reports idle and thus remain unfixed.
So, I'm going through bugzilla and finding bug reports that I honestly
believe are most likely not ever going to get the attention they deserve,
and just trying my best to explain it to people and recommend to them
how to report their bug in the respective upstream project and thus increase
the chances of someone who actively works on DRI or Mesa all day every day
investigating the problem and fixing it.
To report the problem upstream, file a bug report at http://bugs.xfree86.org
and it will likely be reassigned to the DRI project. The success rate of
deferring bugs to upstream developers like this has proven to be quite high
since bugzilla opened up upstream, so this is most likely the fastest way
to see the problem fixed. I can then much more easily investigate the fixes
for inclusion in future RHL releases.
If you file it upstream, please include a URL here to link to the bug.
Hope this helps.
Closing as UPSTREAM
Nobody's provided a URL for me to track this bug upstream anywhere, so I
can't do so. I'm assuming that people who experienced this bug in action,
have upgraded to a newer release and are no longer experiencing the problem,
or that interest has been lost in the problem.
Reopening bug and closing as WONTFIX. If the problem has been reported
upstream anywhere and someone would like it tracked, feel free to reopen
this bug and provide the upstream bug URL.