Bug 304551 - Patch: fix libGL regression caused by mesa-7.0-use_master-r300.patch
Summary: Patch: fix libGL regression caused by mesa-7.0-use_master-r300.patch
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-09-25 07:39 UTC by Hans de Goede
Modified: 2018-04-11 13:26 UTC (History)
5 users (show)

Fixed In Version: 7.0.2-2.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-01-11 22:13:02 UTC
Type: ---

Attachments (Terms of Use)
PATCH fixing maniadrive being slow with current mesa (2.27 KB, patch)
2007-12-28 21:08 UTC, Hans de Goede
no flags Details | Diff
PATCH fixing off by one error in tempreg check in rx00 vertprog code (1.96 KB, patch)
2007-12-28 22:09 UTC, Hans de Goede
no flags Details | Diff

Description Hans de Goede 2007-09-25 07:39:43 UTC
I'm using a radeon 9800 pro, x86_64, Fedora 8 test (kept in sync with rawhide).
I'm the Fedora maintainer of maniadrive: http://maniadrive.raydium.org/

If I downgrade mesa to 6.5.2 (from F-7 updates) and disable shadows maniadrive
works well (with shadows it becomes very slow).

But with 7.0.1 it is slow even with shadows disabled, I do get this message:
File r300_vertprog.c function r300TranslateVertexShader line 1130
Ran out of temps, num temps 13, us 12

I guess the recent r300 vertex prog rewrite is the culprit here, maybe it is an
idea to downgrade the r300 driver to the version in 6.5.2?

And after this Fedora update:

* Thu Aug 16 2007 Dave Airlie <airlied> - 7.0.1-3
- mesa-7.0.1-stable-branch.patch - Add patches from stable branch
  includes support for some Intel chipsets
- mesa-7.0-use_master-r300.patch - Add r300 driver from master

It stayed slow but also become wrongly rendered (all textures seem to be
missing), building a local version without the mesa-7.0-use_master-r300.patch
applied fixes this.

As said I'm a developer / programmer myself, I have almost no experience with
3d hardware programming, but I'm very skilled in C and debugging in general. I
would really like to see this fixed, so please let me know what I can do to

Comment 1 Hans de Goede 2007-09-25 07:40:30 UTC
Also filed upstream:

Comment 2 Matěj Cepl 2007-09-27 15:19:20 UTC
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 3 Hans de Goede 2007-09-28 15:23:47 UTC
GRRR, please stop with these stupid canned replies, which look as if the bug
report wasn't even read. This is _not_ a configuration issue, otherwise it
wouldn't go away with a mesa-libGL downgrade.

These canned replies do not motivate me to take the time to fill detailed bug

The only relevant thing for this bug one may get out of the logs is the card
which I'm using and I already told you what it is a Radeon 9800 pro. For the
record, yesterday I tried this on a laptop with a Radeon 9700 card and there it
happened too, so any r300 card will do to reproduce!

Comment 4 Matěj Cepl 2007-10-01 09:13:50 UTC
Concerning the canned response see my reply to fedora-devel (the bottom line is
-- "if you want to have more beautiful comments, you are free to help me to
triage hundreds of desktop bugs which are still in NEW state despite being half
a year old."). For this particular case, if you want to tell me that
/var/log/Xorg.0.log is useless, because GL is totally hardware agnostic, then I
am afraid I have a bridge for you to sell. Giving up in this case, and letting
developers to decide.


Comment 5 Hans de Goede 2007-10-01 12:26:28 UTC
I'm not saying that this bug is hardware independent, it only happens on
hardware using the r300 driver, and as I've seen it happen on completely
different hardware using this driver (x86_64 desktop, versus i386 laptop), so
yes /var/log/Xorg.0 is useless, as this can be reproduced on any r300 part.

As for letting the developer decide, I'm currently in direct private mail
contact with the upstream author of the r300 vertex code, who is taking me
serious instead of asking for Xorg.log files.

Comment 6 Dave Airlie 2007-10-01 21:55:03 UTC
Upstream is actually the best place to deal with this bug, if a bug fix is put
upstream we can pick it up, but we probably can't develop a fix here considering
how many bugs we have in drivers..

The reason we drag in the r300 master driver is due to RS480 support not being
possible in the earlier version...

Comment 7 Hans de Goede 2007-12-28 14:36:40 UTC
Dave Airlie, adding you to the CC, since its a commit of your that causes part
of the problem.

I've decided to invest some time into this bug, since it currently is one of the
bugs that annoys me the most, so its time to scratch my itch.

There are 2 issues with maniadrive and mesa-7.0 on an r300:
1) Mesa >= 7.0 (clean build from upstream or Fedora packages doesn't matter)
   cause maniadrive to slow to 4 fps. When this happens the following message is
   printed on the terminal:
File r300_vertprog.c function r300TranslateVertexShader line 1130
Ran out of temps, num temps 14, us 13

   I think this is caused by the new GLSL support in 7.0, I would like to
   confirm that GLSL is the cause, is there anyway to turn of GLSL / 
   GL_ARB_vertex_program ?

2) The mesa-7.0-use_master-r300.patch, which I understand is present for good 
   reasons in Fedora's package causes, causes the colors / textures to go all
   wrong (mostly whitish).

   I've spend most of yesterday and a large part of today, trying to find out 
   which git commit has caused this regression and I've finally found the 
   trouble some commit. And luckily its a quite isolated one and not part of
   the swtcl r300 work. The commit causing the colors to go wrong is:

   And then the second chunk. Adding a patch reverting this, or removing it from
   mesa-7.0-use_master-r300.patch, fixes the colors going wrong.

I'll be trying to find a fix issue 1) now, in the mean time it would be nice to
get a mesa update for Fedora including the reversal of the offending commit and
also including the fix for bug 423701, which includes a link to a bugfix made by
upstream after I spend a day finding out which commit exactly caused the
regression reported in bug 423701. While updating, it might be a good idea to
include the below commit too, as that fixes x700 SE cards (according to the

Comment 8 Hans de Goede 2007-12-28 21:08:35 UTC
Created attachment 290506 [details]
PATCH fixing maniadrive being slow with current mesa


After quite some hours of investigating and debugging I've fixed the slowness
issue :)

The problem is that tnl/t_vp_build.c generates vertex programs which use 14
temp variables, and the r300 has exactly 14 temp registers (according to the
current driver).

This becomes a problem because:
1) Certain ARB vertex instructions are emulated on the r300, and the emulation
   code needs a temp register too.
2) Even those vertex programs which do not use the troublesome ARB vertex
   instructions will not work because there is an of by one bug in the check if

   there are enough registers.

This patch fixes the t_vp_build.c code to no require more temp registers then
it actually needs. It takes 2 of the number of temp registers needed by the
generated code in the case of maniadrive, making maniadrive work even with the
off by one bug still present in the r300 code.

I'll write and attach a patch for the off by one bug next.

Comment 9 Hans de Goede 2007-12-28 21:25:23 UTC
I've also mentioned my fixes and attached my patch at the upstream bug report:

Comment 10 Hans de Goede 2007-12-28 22:09:06 UTC
Created attachment 290508 [details]
PATCH fixing off by one error in tempreg check in rx00 vertprog code

This patch makes a slightly bigger change then necessary to fix the bug in
order to make it clearer to the reader of the code what is happening to avoid a
similar error creeping in in the future.

Comment 11 Rahul Sundaram 2007-12-29 19:30:47 UTC
Maniadrive used to segfault on my system and Hans mesa build at
http://koji.fedoraproject.org/koji/taskinfo?taskID=313592 fixes the problem.

My smolt profile is at 

Comment 12 Dave Airlie 2008-01-01 07:48:35 UTC
I've built an updated Mesa in koji, it should land in updates-testing soon.

Comment 13 Hans de Goede 2008-01-01 10:43:14 UTC

A couple of remarks though:

1) You've not included this patch:

I can understand if you are reluctant to revert this in F-8, but please keep in
mind that it wasn't present until rather late in the F-8 testing cycle, and
there were no problems with not having it.

And without this maniadrive is still unusable (and it might effect other
programs too).

2) You may want to consider throwing in this commit, to fix x700 SE cards.
Totally untested by me, I just found it when digging through the r300 
history, it seems a simple fix, and I think x700 SE cards wont work otherwise:
I'm actually surprised this hasn't been committed to upstreams stable branch, an
oversight I guess?

3) You may also want to consider applying the patch attached to bug 425790, 
which seems like an easy score to get some more hardware supported without any
chance for regressions (it just adds a PCI ID).

Talking about this patch, it isn't present upstream in current git master
either, see:

So I guess you want to forward port and commit this upstream too (to both stable
as is and to master ported).

Comment 14 Hans de Goede 2008-01-01 11:04:23 UTC
Scrap remark 1 in my last comment, I've been doing some testing and with my
fixes for the performance issue alone
(mesa-7.0.2-t_vp_build-use-less-temps.patch), the wrong rendering goes away too.

I didn't find this out earlier because I first spend a whole day fixing the
wrong rendering, and then another half day fixing the performance with the
rendering fixed already.

So appearantly your changes reverted in this commit:

Only cause rendering issues when t_vp_build.c generates a tnl program which
cannot be executed in hardware, which is why it was only causing trouble for
maniadrive, as maniadrive has a (sofar) unique combination of tnl options which
caused t_vp_build.c to use to many temps for the hardware.

Still worth investigating futher though.

Comment 15 Fedora Update System 2008-01-03 01:35:46 UTC
mesa-7.0.2-2.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mesa'

Comment 16 Fedora Update System 2008-01-11 22:13:01 UTC
mesa-7.0.2-2.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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