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: *********************************WARN_ONCE********************************* 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 help.
Also filed upstream: https://bugs.freedesktop.org/show_bug.cgi?id=12240
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.
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 reports! 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!
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. Ajax?
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.
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...
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: *********************************WARN_ONCE********************************* 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: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=d7777f45981bf91d2cb31502ba078312b1b4cf13 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 changelog): http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=0b7e0f81591c0b70452ff9250af9b145e8c15adf
Created attachment 290506 [details] PATCH fixing maniadrive being slow with current mesa Okay, 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.
I've also mentioned my fixes and attached my patch at the upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=12240
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.
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 http://smolts.org/show?UUID=3a15b444-3dbe-41d3-9ad4-88331be2d756
I've built an updated Mesa in koji, it should land in updates-testing soon.
Thanks! A couple of remarks though: 1) You've not included this patch: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=cc50edbca2fd3111f9987d4117fa6656599d79dc 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: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=0b7e0f81591c0b70452ff9250af9b145e8c15adf 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: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=blob;h=4fc4c963765099193b6ce287da00bc23707c2e6f;hb=0b7e0f81591c0b70452ff9250af9b145e8c15adf;f=src/mesa/drivers/dri/intel/intel_chipset.h So I guess you want to forward port and commit this upstream too (to both stable as is and to master ported).
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: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=cc50edbca2fd3111f9987d4117fa6656599d79dc 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.
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'
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.