To reproduce: 1. Using Mesa 6.5.1, 6.5.2, or 7.0 built with DRI enabled (i.e. make linux-dri) and a graphics card which produces the following in Xorg.0.log: (--) PCI:*(1:0:0) ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] rev 0, Mem @ 0xe0000000/27, 0xed000000/16, I/O @ 0xa000/8 ... (--) RADEON(0): Chipset: "ATI Radeon VE/7000 QY (AGP/PCI)" (ChipID = 0x5159) 2. Run blender 2.44. I tried both the FC6 RPM and the (non-static) tarball from: http://www.blender.org/download/get-blender/ 3. Click "Add Multires". Click "Add Level" a few times. Click "Object Mode" and switch to "Sculpt Mode". Select the "Sculpt" tab (next to the Multires tab). Click "Grab". Left-click and drag on the object several times -- avoid the green and red arrows. Expected results: Each drag should cause part of the object to be pulled out. Actual results: Approximately 80% of the time nothing happens except that the brush circle will not move for a second after you release the mouse. More details: The problem does NOT occur when using Mesa 7.0 built with "make linux-x86", nor with the "Static MesaGL" version of blender available from: http://www.blender.org/download/get-blender/ That makes me think the problem is in the Mesa DRI driver. (Suprisingly setting LIBGL_ALWAYS_INDIRECT=1 does NOT solve the problem. In fact, it doesn't appear to be disabling DRI. For example, when using Mesa compiled without DRI, it takes a very long time for blender to draw it's splash screen -- the borders are drawn one pixel at a time. However, I do NOT see that effect when I use a DRI build with LIBGL_ALWAYS_INDIRECT=1.) Setting the following env vars to 1 (one at time) does NOT solve the sculpting problem: RADEON_COMPAT LIBGL_PERFORMANCE_BOXES RADEON_NO_IRQS RADEON_NO_USLEEPS RADEON_TCL_FORCE_ENABLE RADEON_TCL_FORCE_DISABLE RADEON_NO_VTXFMT RADEON_NO_CODEGEN MESA_NO_ASM MESA_NO_MMX MESA_NO_3DNOW MESA_NO_SSE MESA_NO_DITHER Various 3D games (e.g. GL-117, PPRacer, Supertuxkart, TORCS) seem to work fine on the same machine. I'm happy to help debug the problem and provide any other information that I can. Is there a way to determine which OpenGL calls are being made when the problem is occuring?
(In reply to comment #0) Can't say much for the bug itself, just some comments. > (Suprisingly setting LIBGL_ALWAYS_INDIRECT=1 does NOT solve the problem. In > fact, it doesn't appear to be disabling DRI. For example, when using Mesa > compiled without DRI, it takes a very long time for blender to draw it's splash > screen -- the borders are drawn one pixel at a time. However, I do NOT see > that effect when I use a DRI build with LIBGL_ALWAYS_INDIRECT=1.) You may have aiglx enabled, in which case you get accelerated indirect rendering. > Setting the following env vars to 1 (one at time) does NOT solve the sculpting > problem: Most (all?) of them are no longer recognized, some are completely obsolete the others have been replaced by driconf-style ones. About the only one which might help with rendering problems is tcl_mode=0, but since your chip doesn't have tcl in the first place it won't do anything... Try driconf if you want to play around with driver settings (even though it won't help for your problem). > MESA_NO_ASM > MESA_NO_MMX > MESA_NO_3DNOW > MESA_NO_SSE > MESA_NO_DITHER It's highly unlikely these would help if it works correctly with software mesa (and they don't do anything if you built linux-dri and not linux-dri-x86, except the no_dither one). > Various 3D games (e.g. GL-117, PPRacer, Supertuxkart, TORCS) seem to work fine > on the same machine. > > I'm happy to help debug the problem and provide any other information that I > can. Is there a way to determine which OpenGL calls are being made when the > problem is occuring? When you say 80% of the time nothing happens, the other (seemingly random?) 20% it works completely correct or are there other errors?
(In reply to comment #1) > > (Suprisingly setting LIBGL_ALWAYS_INDIRECT=1 does NOT solve the problem. > You may have aiglx enabled, in which case you get accelerated indirect > rendering. Yes, that was the case. When I disable AIGLX and use LIBGL_ALWAYS_INDIRECT=1, the problem goes away. With AIGLX disabled but LIBGL_ALWAYS_INDIRECT not set, I still see the problem. > > Setting the following env vars to 1 (one at time) does NOT solve the sculpting > > problem: > Most (all?) of them are no longer recognized, some are completely obsolete the > others have been replaced by driconf-style ones. OK. FYI, I found them mentioned at: http://dri.sourceforge.net/doc/dri_driver_features.phtml So that page should probably be updated. > When you say 80% of the time nothing happens, the other (seemingly random?) 20% > it works completely correct or are there other errors? The 20% that it works seems to be random and I don't see any other errors when it works.
A clue! It works with Mesa 6.4.2.
(In reply to comment #3) > A clue! It works with Mesa 6.4.2. Oops. I was wrong. 6.4.2 fails as well. I was confused because even though I did "make linux-dri", Mesa wasn't using the DRI drivers. The difference was that I built 6.4.2 with aiglx disabled on the X server. It looks like that changes whether Mesa uses DRI by default? Anyway, when I restarted X with aiglx enabled and tried the same 6.4.2 build, it used the DRI driver and the problem occurred again. Also, upon further examination I *think* the 20% of the time that it seems to work, the grabbed portion of the object doesn't track the pointer as well as it should during the drag.
Do you still have issue with recent mesa ?
I've since upgraded to Fedora 10 and the problem no occurs. Fedora 10 includes the following packages: mesa-libGLU-devel-7.2-0.15.fc10.i386 mesa-libGLU-7.2-0.15.fc10.i386 mesa-libGL-devel-7.2-0.15.fc10.i386 mesa-libGL-7.2-0.15.fc10.i386 mesa-dri-drivers-7.2-0.15.fc10.i386 blender-2.48a-5.fc10.i386
Just tested this on a x1650 with r300g build from a few days ago ant the problem still exists.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/267.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.