|Summary:||r300 DRI misrenders 3D objects|
|Product:||Mesa||Reporter:||Bernhard Rosenkraenzer <bero>|
|Component:||Drivers/DRI/r300||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED NOTOURBUG||QA Contact:|
|Priority:||medium||CC:||dberkholz, freedesktop, tropikhajma, z3ro.geek|
|i915 platform:||i915 features:|
Screenshot showing garbled blender
preprocessed code of r300SetupPixelShader()
assembly code of r300SetupPixelShader() when built with -O2
diff of assembly code of r300SetupPixelShader() when building with "-O2" and "-O2 -fno-tree-vrp"
Description Bernhard Rosenkraenzer 2007-06-26 10:09:42 UTC
When trying to use DRI enabled applications on an R300 (ATI Mobility Radeon 9600 M10, PCI ID 1002:4e50 subsystem 1025:0046; 1400x1050 at 24 bpp), the application's window is garbled (there is no crash, and it looks like the application is working, just not drawing the correct items). Neither X logs nor dmesg show any error messages, LIBGL_DEBUG=verbose glxinfo doesn't report anything odd. 2D acceleration is working perfectly, identical software works well (including DRI) with an r200 card. xorg-server 188.8.131.52 xf86-video-ati 6.6.192 Mesa 6.5.3 (also tried 7.0 with patched xorg-server, same effect) libdrm from git Linux 2.6.22-rc4 (tried both stock kernel and kernel with current DRI git modules; also tried 2.6.21) glibc 2.6 gcc 4.2 The same machine worked well roughly a year ago, with xorg-server 1.1.1, xf86-video-ati 6.6.1, libdrm 2.1, Linux 2.6.18-rc2, glibc 2.4, gcc 4.1.1 Misrenderings depend on the application. blender just garbles its window (will attach a screenshot), tuxracer/ppracer draw the background and nothing else (possibly the menus etc. are hidden behind the background), glxgears shows just a black window and a pretty high FPS (9281 frames in 5.0 seconds = 1856.061 FPS 9389 frames in 5.0 seconds = 1877.744 FPS)
Comment 1 Bernhard Rosenkraenzer 2007-06-26 10:10:43 UTC
Created attachment 10459 [details] Screenshot showing garbled blender
Comment 2 Oliver McFadden 2007-06-26 10:40:41 UTC
This is probably one of my commits... Maybe the vertex shader clean up. I'm compiling blender now and I'll start bisecting this assuming I can reproduce the bug. :-)
Comment 3 Michel Dänzer 2007-06-26 10:52:29 UTC
(In reply to comment #0) > The same machine worked well roughly a year ago, with xorg-server 1.1.1, > xf86-video-ati 6.6.1, libdrm 2.1, Linux 2.6.18-rc2, glibc 2.4, gcc 4.1.1 What version of Mesa was that? Does that version still work with the rest of the system unchanged?
Comment 4 Oliver McFadden 2007-06-26 10:58:29 UTC
I just tested Blender 2.44 with Mesa from git and it worked fine... Could you try with Mesa from git?
Comment 5 Bernhard Rosenkraenzer 2007-06-26 11:50:51 UTC
Mesa from today's git does the same thing as 7.0 (and 6.5.3). The last Mesa version known to work for me is a CVS snapshot from 2006/07/19. I'll try putting that in (it'll take a while to adjust xorg-server 184.108.40.206 to compile against it though) next.
Comment 6 Papadakos Panagiotis 2007-06-26 11:55:18 UTC
(In reply to comment #5) > Mesa from today's git does the same thing as 7.0 (and 6.5.3). > > The last Mesa version known to work for me is a CVS snapshot from 2006/07/19. > I'll try putting that in (it'll take a while to adjust xorg-server 220.127.116.11 to > compile against it though) next. > Well I don't have such problems with latest mesa.
Comment 7 Adam K Kirchhoff 2007-06-26 12:19:51 UTC
Nor I. There were problems (which look nothing like the attached screenshot) with blender up till last week, but they were remedied for me and it works flawlessly. I am running Xorg 7.2, so I don't know if that would make any difference.
Comment 8 Bernhard Rosenkraenzer 2007-06-26 16:22:28 UTC
Going back to the old Mesa while leaving the rest the same doesn't fix things -- chances are this is an interoperability problem with something else. Is anyone for whom this works using gcc 4.2.x and/or xorg-server 1.3.0?
Comment 9 Adam K Kirchhoff 2007-06-26 16:46:19 UTC
I've now tried with xorg-server 1.3.0 and it works fine. gcc on this machine is 4.1.2.
Comment 10 Michel Dänzer 2007-06-26 23:38:14 UTC
(In reply to comment #8) > Going back to the old Mesa while leaving the rest the same doesn't fix things > -- chances are this is an interoperability problem with something else. > > Is anyone for whom this works using gcc 4.2.x and/or xorg-server 1.3.0? xorg-server shouldn't really matter (in particular, you don't need to rebuild it at all or even restart it to try different 3D drivers), so the prime suspect would appear to be gcc - the Mesa codebase is relatively fragile wrt compiler optimizations. Does it work if you build Mesa with the old compiler, or if you build the linux-dri or linux-dri-debug target instead of linux-dri-x86? I guess a simple first test for this theory would be to try the old Mesa binaries.
Comment 11 Papadakos Panagiotis 2007-06-27 01:04:14 UTC
(In reply to comment #9) > I've now tried with xorg-server 1.3.0 and it works fine. gcc on this machine > is 4.1.2. > And here it works OK with gcc version 4.2.1 20070606 (prerelease).
Comment 12 Bernhard Rosenkraenzer 2007-06-27 06:50:02 UTC
It's definitely a compiler thing. If I just build it (7.0) with make linux-dri-x86 OPT_FLAGS="-O0" it works perfectly. I'll try to figure out what flag exactly causes it to break.
Comment 13 Bernhard Rosenkraenzer 2007-06-27 14:02:04 UTC
The culprit is -O2, it works at -O0 and -O1. Will trace it down to a specific part of -O2 and report it to the gcc guys
Comment 14 Michel Dänzer 2007-06-27 23:24:12 UTC
(In reply to comment #13) > The culprit is -O2, it works at -O0 and -O1. Will trace it down to a specific > part of -O2 and report it to the gcc guys The Mesa codebase is not strict aliasing safe, make sure you use -fno-strict-aliasing with -O2.
Comment 15 Bernhard Rosenkraenzer 2007-06-28 03:34:25 UTC
I know -- the screenshot is the result of -O2 -march=i686 -fno-strict-aliasing -fweb -frename-registers. (And the r200 driver and software rendering compiled with those flags works perfectly, it's just r300). Still getting the same results with -O2 and a number of the optimizations that are usually part of -O2 disabled (-O2 -fno-thread-jumps -fno-crossjumping -fno-optimize-sibling-calls -fno-cse-follow-jumps -fno-cse-skip-blocks -fno-gcse -fno-gcse-lm -fno-expensive-optimizations -fno-strict-aliasing) Currently building with some more optimizations disabled.
Comment 16 Roland Scheidegger 2007-06-28 03:51:50 UTC
(In reply to comment #15) > Currently building with some more optimizations disabled. You could try without the -ffast-math switch. It doesn't really do the same things if optimizations are enabled or not (though -O1 was enough to trigger the different behaviour for me (bug #9856)).
Comment 17 Bernhard Rosenkraenzer 2007-06-29 01:08:35 UTC
-ftree-vrp (enabled by default at -O2 and higher) is the culprit. If you compile r300_state.c with -O2 -fno-tree-vrp, everything works as expected. All other files can be compiled with full -O2.
Comment 18 Bernhard Rosenkraenzer 2007-06-29 01:21:22 UTC
Comment 19 Bernhard Rosenkraenzer 2007-07-04 05:19:05 UTC
The gcc guys claim -fno-tree-vrp doesn't generate any significant difference in the asm output, yet that flag definitely fixes it here. Could this be some strange timing issue triggered by unexpectedly fast execution of r300SetupPixelShader()?
Comment 20 Jerome Glisse 2007-07-04 07:16:13 UTC
How did you narrowed down to this specific function ? I also don't see any differences in preprocessed source.
Comment 21 Bernhard Rosenkraenzer 2007-07-04 07:21:39 UTC
The preprocessor output can't be different because -f[no-]tree-vrp doesn't affect the preprocessor -- it affects the generated assembly code. I narrowed down the function by splitting radeon_state.c into 2 files, compiling one with -ftree-vrp and one with -fno-tree-vrp, moving functions around between the 2 files until a version with only 1 function in the -ftree-vrp one broke (removing any "static" keywords of course).
Comment 22 Jerome Glisse 2007-07-04 07:32:18 UTC
Can you provide asm output of the function with & without the -ftree-vrp options, i haven't access to gcc 4.2.1.
Comment 23 Olivier Blin 2007-08-07 08:22:32 UTC
I experience the same problem on a RV350 with blender, building with -O2 also triggers a hardlock when using compiz. It works fine when building r300_state.c with -fno-tree-vrp. It also runs fine when building with -O3, or when building with -O2 with gcc 4.3 I've isolated the code of r300SetupPixelShader() in a separate file, and diffed the assembly code. It shows this a gcc bug (a teammate will add more info on the upstream gcc bug report). For reference, I'll attach the preprocessed and assembly files, as well as the assembly diff when building with -fno-tree-vrp, but this bug can probably be closed as INVALID.
Comment 24 Olivier Blin 2007-08-07 08:23:17 UTC
Created attachment 11032 [details] preprocessed code of r300SetupPixelShader()
Comment 25 Olivier Blin 2007-08-07 08:23:45 UTC
Created attachment 11033 [details] assembly code of r300SetupPixelShader() when built with -O2
Comment 26 Olivier Blin 2007-08-07 08:24:45 UTC
Created attachment 11034 [details] diff of assembly code of r300SetupPixelShader() when building with "-O2" and "-O2 -fno-tree-vrp"
Comment 27 Pascal "Pixel" Rigaux 2007-08-07 15:50:56 UTC
nb: -fno-ivopts option can be used instead of -fno-tree-vrp since the vrp issue is triggered by ivopts issue :)