Bug 11495 - blender sculpt mode is very flakey when using DRI
Summary: blender sculpt mode is very flakey when using DRI
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100 (show other bugs)
Version: 6.5
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-07 08:43 UTC by Dean Brettle
Modified: 2010-10-17 01:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dean Brettle 2007-07-07 08:43:51 UTC
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?
Comment 1 Roland Scheidegger 2007-07-07 09:46:40 UTC
(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?

Comment 2 Dean Brettle 2007-07-07 11:32:47 UTC
(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.
 

Comment 3 Dean Brettle 2007-07-07 12:09:32 UTC
A clue!  It works with Mesa 6.4.2.
Comment 4 Dean Brettle 2007-07-07 15:22:39 UTC
(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.
Comment 5 Jerome Glisse 2009-05-18 07:43:00 UTC
Do you still have issue with recent mesa ?
Comment 6 Dean Brettle 2009-05-18 08:39:48 UTC
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

Comment 7 Christoph Brill 2010-10-17 01:42:18 UTC
Just tested this on a x1650 with r300g build from a few days ago ant the problem still exists.


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.