Created attachment 125272 [details]
Here is a link to a video of the bug happening
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
OS: Ubuntu 16.04 xenial
Kernel: x86_64 Linux 4.7.0-040700rc5-generic
Shell: bash 4.3.46
DE: Unity 7.4.0
WM Theme: Ambiance
, 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
Created attachment 125273 [details]
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.
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?
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.
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 :)
But sync on seems cleared it for the window once, but if in fullscreen (ALT+F11) corruption appear with both vblank on/off.
modesetting driver also show this corruption. No corruption with LIBGL_ALWAYS_SOFTWARE=1 etc...
Enough testing from me, bug is there.
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.
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 :)
If I also set it to triple buffer the problem has gone away.
Should I report this on the blender bug tracker?
(In reply to dave from comment #10)
> Should I report this on the blender bug tracker?
Resolving as not our bug.
*** Bug 98286 has been marked as a duplicate of this bug. ***
*** Bug 100266 has been marked as a duplicate of this bug. ***
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.
*** Bug 102814 has been marked as a duplicate of this bug. ***