| Summary: | Tahiti+DRI3+Unity+Blender corruption | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | dave <eunbolt> |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | anthoine.bourgeois, darkdefende, dark.shadow4, eunbolt, freedesktop |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Xorg.0.log output
lshw output |
||
|
Description
dave
2016-07-23 11:02:12 UTC
Created attachment 125273 [details]
lshw output
Hello, 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. Thanks Dave 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? Yes, please. 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. *** |
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.