| Bug ID | 97059 |
|---|---|
| Summary | Tahiti+DRI3+Unity+Blender corruption |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | eunbolt@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 125272 = [details] Xorg.0.log output Here is a link to a video of the bug happening https://youtu.be/tMs4QSW0OmY -=3Dglxinfo output=3D- 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 -=3Dscreenfetch output=3D- 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 attached
Hello, Sorry for not explaining the issue, I don't know how to edit the first comm= ent. 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. Thanks Dave
Can't seem to reproduce this with blender 2.77.a+dfsg0-5 . Wh= ich versions have you tried? Does setting the environment variable LIBGL_DRI3_DISABLE=3D1 for the blender process avoid the problem?
I have always had this issue with this card and blender[I norm= ally 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=3D1 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=3D1 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=3D3 , but with vblank_mode=3D0 it is ther= e :)
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=3D1 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 bu= ffer 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 c= an 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 aw= ay :)
If I also set it to triple buffer the problem has gone away. Should I report this on the blender bug tracker?
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTOURBUG |
| Status | NEW | RESOLVED |
(In reply to dave from comment #10) > Should I report this on the blender bug tracker?= Yes, please. Resolving as not our bug.
| What | Removed | Added |
|---|---|---|
| CC | darkdefende@gmail.com |
*** Bug 98286 has been marked as a dupl= icate of this bug. ***
| What | Removed | Added |
|---|---|---|
| CC | dark.shadow4@web.de |
*** Bug 100266 has been marked as a du= plicate 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 th= at seems like the better approach.
| What | Removed | Added |
|---|---|---|
| CC | freedesktop@ca.sh13.net |
*** Bug 102814 has been marked as a du= plicate of this bug. ***