Bug 110448

Summary:

brief corruption when opening Blender benchmark window

Product:

xorg

Reporter:

tempel.julian

Component:

Driver/AMDgpu

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED NOTOURBUG

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

Version:

git

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
corruption when starting blender benchmark	none
xorg log	none
glxinfo log	none
dmesg	none

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.