Bug 97059 - Tahiti+DRI3+Unity+Blender corruption
Summary: Tahiti+DRI3+Unity+Blender corruption
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
: 98286 100266 102814 (view as bug list)
Depends on:
Reported: 2016-07-23 11:02 UTC by dave
Modified: 2017-10-05 07:06 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

Xorg.0.log output (69.25 KB, text/plain)
2016-07-23 11:02 UTC, dave
lshw output (1.18 KB, text/plain)
2016-07-23 11:02 UTC, dave

Description dave 2016-07-23 11:02:12 UTC
Created attachment 125272 [details]
Xorg.0.log output

Here is a link to a video of the bug happening

-=glxinfo output=-
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel - padoka PPA
OpenGL version string: 3.0 Mesa 12.1.0-devel - padoka PPA
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 12.1.0-devel - padoka PPA

-=screenfetch output=-
 OS: Ubuntu 16.04 xenial
 Kernel: x86_64 Linux 4.7.0-040700rc5-generic
 Uptime: 5m
 Packages: 2937
 Shell: bash 4.3.46
 Resolution: 1920x1080
 DE: Unity 7.4.0
 WM: Compiz
 WM Theme: Ambiance
Ambiance [GTK2]
, Ambiance [GTK3]
 Icon Theme: ubuntu-mono-dark
 Font: Ubuntu 11
 CPU: AMD Phenom II X4 965 @ 3.4GHz
 GPU: Gallium 0.4 on AMD TAHITI (DRM 2.45.0 / 4.7.0-040700rc5-generic, LLVM 4.0.0)
 RAM: 2129MiB / 16049MiB

/var/log/Xorg.0.log output
Comment 1 dave 2016-07-23 11:02:41 UTC
Created attachment 125273 [details]
lshw output
Comment 2 dave 2016-07-23 11:05:53 UTC

Sorry for not explaining the issue, I don't know how to edit the first comment.

I have noticed a bug in the rendering of blender using Radeonsi drivers and dri3. This happens with different versions of blender also.

I'm using padoka's PPA and ubuntu 16.04. more details in the First comment.

If I am missing anything let me know and i will get more information.

Comment 3 Michel Dänzer 2016-07-25 10:01:37 UTC
Can't seem to reproduce this with blender 2.77.a+dfsg0-5 .  Which versions have you tried?

Does setting the environment variable LIBGL_DRI3_DISABLE=1 for the blender process avoid the problem?
Comment 4 dave 2016-07-25 12:50:21 UTC
I have always had this issue with this card and blender[I normally keep up to date with blenders releases](this is only only application I have noticed it on.) issue affects blender 2.60a also. I can try more if you would like.

setting the variable LIBGL_DRI3_DISABLE=1 seems to make the issue go away.
Comment 5 smoki 2016-07-25 19:16:14 UTC
 I reproduced this on current Debian Sid and Kabini with current distro packages, same blender as Michel's.

 LIBGL_DRI3_DISABLE=1 fixes it, but...

 But it is tricky one, it has something to do with vsync it seems, as also is not reproducable with vblank_mode=3 , but with vblank_mode=0 it is there :)
Comment 6 smoki 2016-07-26 03:02:06 UTC
 But sync on seems cleared it for the window once, but if in fullscreen (ALT+F11) corruption appear with both vblank on/off.
Comment 7 smoki 2016-07-26 03:30:52 UTC
 modesetting driver also show this corruption. No corruption with LIBGL_ALWAYS_SOFTWARE=1 etc...

 Enough testing from me, bug is there.
Comment 8 Michel Dänzer 2016-07-26 04:00:08 UTC
I suspect this is a blender bug. It clearly doesn't render at all to the corrupted parts of its window, but AFAICT it doesn't use any of the GLX_EXT_buffer_age, GLX_OML_swap_method or GLX_INTEL_swap_event extensions to find out what if any guarantees there are about the contents of the back buffer after a buffer swap. blender's assumptions about that may happen to be valid with DRI2, which can only use up to two buffers, but not with DRI3, which can use more.
Comment 9 smoki 2016-07-26 04:41:25 UTC
 Yeah possible Michel, i actually played a little bit with his options and found this:

 CTRL+ALT+U > System > Window Draw Method

 Default is Automatic and if i set it to 'Triple Buffer' this issue goes away :)
Comment 10 dave 2016-07-26 05:58:31 UTC
If I also set it to triple buffer the problem has gone away.
Should I report this on the blender bug tracker?
Comment 11 Michel Dänzer 2016-07-26 06:24:21 UTC
(In reply to dave from comment #10)
> Should I report this on the blender bug tracker?

Yes, please.

Resolving as not our bug.
Comment 12 Michel Dänzer 2016-10-17 11:32:50 UTC
*** Bug 98286 has been marked as a duplicate of this bug. ***
Comment 13 Michel Dänzer 2017-03-18 02:28:24 UTC
*** Bug 100266 has been marked as a duplicate of this bug. ***
Comment 14 Fabian Maurer 2017-03-18 03:12:26 UTC
The opengl calls blender make are faulty, since a trace doesn't render properly on windows with proprietary AMD drivers either.

Though I still want to ask, could we get rid of the random contents? Under windows it's just black instead of drawing random images. To me at least that seems like the better approach.
Comment 15 Michel Dänzer 2017-10-04 15:39:36 UTC
*** Bug 102814 has been marked as a duplicate of this bug. ***

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.