Bug 110448 - brief corruption when opening Blender benchmark window
Summary: brief corruption when opening Blender benchmark window
Status: RESOLVED NOTOURBUG
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/AMDgpu (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-16 09:47 UTC by tempel.julian
Modified: 2019-04-17 08:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
corruption when starting blender benchmark (754.81 KB, image/png)
2019-04-16 09:47 UTC, tempel.julian
no flags Details
xorg log (30.75 KB, text/plain)
2019-04-16 17:24 UTC, tempel.julian
no flags Details
glxinfo log (145.35 KB, text/plain)
2019-04-16 17:25 UTC, tempel.julian
no flags Details
dmesg (93.55 KB, text/plain)
2019-04-16 17:25 UTC, tempel.julian
no flags Details

Description tempel.julian 2019-04-16 09:47:13 UTC
Created attachment 143989 [details]
corruption when starting blender benchmark

When I start the Blender benchmark, I usually get brief corruption like shown in the attached picture.
This probably is what I mentioned in this ticket as a sidenote:
https://gitlab.freedesktop.org/xorg/xserver/issues/636#note_144258

Happens with both amdgpu DDX and modesetting.

Tested with altest xserver-git and xf86-video-amdgpu-git.

Benchmark can be obtained from here:
https://opendata.blender.org/
Comment 1 tempel.julian 2019-04-16 09:47:51 UTC
Forgot to mention: Happens with and without compositor.
Comment 2 Michel Dänzer 2019-04-16 15:07:55 UTC
(In reply to tempel.julian from comment #0)
> Happens with both amdgpu DDX and modesetting.

That indicates against it being an xf86-video-amdgpu bug then. It sounds like a blender or Mesa issue most likely.

I can't seem to reproduce. Please attach the corresponding Xorg log file and output of dmesg and glxinfo.
Comment 3 tempel.julian 2019-04-16 17:24:48 UTC
Created attachment 143994 [details]
xorg log
Comment 4 tempel.julian 2019-04-16 17:25:11 UTC
Created attachment 143995 [details]
glxinfo log
Comment 5 tempel.julian 2019-04-16 17:25:30 UTC
Created attachment 143996 [details]
dmesg
Comment 6 tempel.julian 2019-04-16 17:29:57 UTC
Seems to happen less likely with KWin than with Compton or no compositor.

My guess as a layman would be that the program initializes GL rendering inside the window, but freezes for a moment while doing so and then shows the artifacts until it is done initializing.

In that case it would be nice if the mesa/xorg infrastructure could prevent such artifacts, instead of expecting of the program to initialize without interruption, as there always will be such edge cases.
At least I'm not aware of similar artifacts on the Windows platform.
Comment 7 Michel Dänzer 2019-04-17 07:37:02 UTC
Can you try if this also happens with Mesa 19.0 or older?
Comment 8 Michel Dänzer 2019-04-17 08:10:01 UTC
I was able to reproduce it after all, and upon inspection with apitrace and gdb, it's indeed a blender bug. It calls glXSwapBuffers without drawing anything to the back buffer before, which is basically like asking "please put up random stuff as the window contents".
Comment 9 tempel.julian 2019-04-17 08:27:30 UTC
Thanks for looking into it. Is it possible for xorg/mesa to just show solid black instead of "modern art" in such cases? 

Of course not an important matter at all, compared to other things like xwayland fake 60 Hz windowed behavior etc. :)
Comment 10 Michel Dänzer 2019-04-17 08:38:00 UTC
(In reply to tempel.julian from comment #9)
> Thanks for looking into it. Is it possible for xorg/mesa to just show solid
> black instead of "modern art" in such cases? 

Xorg can't know that the client really wanted to present something else than what it asked to present. :)

Mesa might be able to work around this, but I'm not sure it's worth it or even a good idea.


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.