Bug 89131 - [Bisected] Graphical corruption in Weston, shows old framebuffer pieces
Summary: [Bisected] Graphical corruption in Weston, shows old framebuffer pieces
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Depends on:
Reported: 2015-02-13 06:49 UTC by James Harvey
Modified: 2015-07-06 12:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

weston-corruption.png (894.97 KB, image/png)
2015-02-13 06:49 UTC, James Harvey
dmesg and weston output (60.91 KB, text/plain)
2015-02-13 06:52 UTC, James Harvey

Description James Harvey 2015-02-13 06:49:35 UTC
Created attachment 113450 [details]

Weston shows graphical corruption when run as regular user. Looks like old framebuffer data is getting reused (i.e. partial text and images from firefox or the desktop). Tested inside X and on console with weston-launch.  Running as root shows no corruption.  Bisected to mesa commit below:

Mesa 10.6.0-devel (git-3f1e128)
wayland (git-52d971c)
westonn (git-ad1218f)

commit 0467a52dc3f7d51eeb51179ce2f9871758ecacb1
Author: Park, Jeongmin <pjm0616@gmail.com>
Date:   Sat Feb 7 17:53:48 2015 +0900

    st/dri: Make depth buffer optional for postprocessing
    Since only pp_jimenezmlaa uses depth buffer, we can make it optional.
    Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Comment 1 James Harvey 2015-02-13 06:52:27 UTC
Created attachment 113451 [details]
dmesg and weston output
Comment 2 Michel Dänzer 2015-02-14 02:42:33 UTC
Have you enabled any of pp_celshade / pp_jimenezmlaa / pp_jimenezmlaa_color / pp_nored / pp_nogreen / pp_noblue in /etc/drirc or ~/.drirc or the environment?
Comment 3 James Harvey 2015-02-14 06:47:16 UTC
Hi Michel,
 Yes, both pp_jimenezmlaa and pp_jimenezmlaa_color were set to 8.  Changing pp_jimenezmlaa to zero or setting "always_have_depth_buffer=true" seems to fix the problem.  Would that mean this is a bug in weston instead? Something along the lines of failing to check that a depth buffer exists before using it?
Comment 4 Michel Dänzer 2015-02-17 04:19:16 UTC
Sounds like maybe pp_jimenezmlaa gets enabled even when there's no depth buffer.

Do you really want to use those post-processing effects with weston, though? :)
Comment 5 Park, Jeongmin 2015-02-17 04:55:48 UTC
I moved depth buffer checks from dri*.c to pp_jimenezmlaa() per Brian's comment
here: https://bugs.freedesktop.org/show_bug.cgi?id=88962
depth buffer check was added to pp_mlaa.c in 2e6ba6afdb62e80689b844c7267272d261db172c
and removed from dri*.c in 0467a52dc3f7d51eeb51179ce2f9871758ecacb1

This bug seems to be caused by my patch didn't check if pp_jimenezmlaa() was failed.
In pp_run.c, if there are multiple postprocess stages(ppq->n_filters > 1)
so that it requires a temp buffer(ppq->tmp[]), and pp_jimenzmlaa return
immediately without writing to 'out', then the temp buffer would have old data.
Comment 6 James Harvey 2015-02-18 05:42:27 UTC
@Michel - well, perhaps not... :)

@Park, Jeongmin - Thanks for taking the time to dig into this.  I realize this bug is probably a low priority itme, but if you do find time to add a check for the failure condition it would be appreciated.
Comment 7 Emil Velikov 2015-07-06 12:34:15 UTC
The following patch is part of mesa since 10.5.7. Feel free to reopen if it doesn't resolve the issue.

commit 25e9ae2b79f32631e7255807a242e5fc4e39984c
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Tue May 26 19:32:36 2015 +0200

    st/dri: fix postprocessing crash when there's no depth buffer

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.