Bug 57814 - GL(X) apps garbled with Matrox G450 and stock config/drivers
Summary: GL(X) apps garbled with Matrox G450 and stock config/drivers
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL: http://www.burn.net/~vom/matrox-glx-p...
Keywords: MoveUpstream
Depends On:
Blocks: 82777
TreeView+ depends on / blocked
Reported: 2001-12-24 18:04 UTC by brandon
Modified: 2007-04-18 16:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-17 09:42:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XFree86.0.log (27.45 KB, text/plain)
2001-12-24 18:27 UTC, brandon
no flags Details
/var/log/dmesg (6.04 KB, text/plain)
2001-12-24 18:29 UTC, brandon
no flags Details
glxinfo output (2.47 KB, text/plain)
2001-12-24 18:31 UTC, brandon
no flags Details
xdpyinfo output (5.88 KB, text/plain)
2001-12-24 18:32 UTC, brandon
no flags Details

Description brandon 2001-12-24 18:04:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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
garbled output.

Version-Release number of selected component (if applicable):

How reproducible:

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 :)

Additional info:

Comment 1 brandon 2001-12-24 18:27:54 UTC
Created attachment 41310 [details]

Comment 2 brandon 2001-12-24 18:29:34 UTC
Created attachment 41311 [details]

Comment 3 brandon 2001-12-24 18:31:51 UTC
Created attachment 41312 [details]
glxinfo output

Comment 4 brandon 2001-12-24 18:32:13 UTC
Created attachment 41313 [details]
xdpyinfo output

Comment 5 Vladimir Florinski 2001-12-25 04:57:42 UTC
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.

Comment 6 Mike A. Harris 2002-01-25 00:12:19 UTC
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.

Comment 7 Vladimir Florinski 2002-01-26 08:41:13 UTC
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.

Comment 8 Mike A. Harris 2002-02-09 19:34:47 UTC
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.


Comment 9 Andrew Huntwork 2002-03-06 06:29:22 UTC
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)

Comment 10 Mike A. Harris 2002-12-19 09:28:05 UTC
Does this still occur in RHL 7.3 and/or RHL 8.0?  What about rawhide (if
anyone has tried rawhide XFree86)?


Comment 11 Vladimir Florinski 2003-01-04 23:28:15 UTC
The bug is still present in RH 7.3. I don't have 8.0, so cannot comment on that.

Comment 12 Mike A. Harris 2003-04-15 08:34:15 UTC
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

Comment 13 Mike A. Harris 2003-07-17 09:41:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.