blender sculpt mode is very flakey when using DRI
Submitted by Dean Brettle
Assigned to Default DRI bug account
- 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)
Run blender 2.44. I tried both the FC6 RPM and the (non-static) tarball from: http://www.blender.org/download/get-blender/
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.
Each drag should cause part of the object to be pulled out.
Approximately 80% of the time nothing happens except that the brush circle will not move for a second after you release the mouse.
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:
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?